Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*XFS\s+Lock\s+debugging\s+noise\s+or\s+real\s+problem\?\s*$/: 18 ]

Total 18 documents matching your query.

1. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: "Linda A. Walsh" <xfs@xxxxxxxxx>
Date: Tue, 12 Aug 2008 15:28:46 -0700
Is it also known, (and the same bug) when you get the lock warnings when doing "xfs_restore", as well (dio_get_page and xfs_ilock)... Doesn't give me the warm & fuzzies, but I'm sure you've heard tha
/archives/xfs/2008-08/msg00200.html (9,568 bytes)

2. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 13 Aug 2008 10:58:52 +1000
That's the mm code calling fput() with the mmap_sem held. That's a problem in the VM code, which XFS can do nothing about. The normal I/O paths always lock the inode first, then (if a page fault occu
/archives/xfs/2008-08/msg00203.html (10,604 bytes)

3. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: Linda Walsh <xfs@xxxxxxxxx>
Date: Wed, 13 Aug 2008 15:05:13 -0700
Dave Chinner wrote: Once again, "a problem with the generic code inverting the normal lock order". This one cannot deadlock, though, because by definition any inode on the unused list is, well, unuse
/archives/xfs/2008-08/msg00222.html (11,025 bytes)

4. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 14 Aug 2008 10:41:01 +1000
generic code == non-filesystem specific kernel code that interfaces with the filesystem code. Any filesystem that does memory allocation with the same type of lock held that it might take when reclai
/archives/xfs/2008-08/msg00225.html (12,314 bytes)

5. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: Linda Walsh <xfs@xxxxxxxxx>
Date: Wed, 13 Aug 2008 18:04:16 -0700
Dave Chinner wrote: I've asked the lockdep ppl to treat stuff like memory reclaim and the iprune_mutex specially because of this recursive calling nature of memory reclaim, but so far nothing has hap
/archives/xfs/2008-08/msg00228.html (11,099 bytes)

6. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 14 Aug 2008 12:01:11 +1000
None of those applications use the swap extents code in XFS, so if they are reporting problems related to xfs_fsr, then it's the xfs_fsr locking that is triggering these later problems. Fixing the sw
/archives/xfs/2008-08/msg00229.html (12,288 bytes)

7. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: xx>
Date: Tue, 12 Aug 2008 15:28:46 -0700
Is it also known, (and the same bug) when you get the lock warnings when doing "xfs_restore", as well (dio_get_page and xfs_ilock)... Doesn't give me the warm & fuzzies, but I'm sure you've heard tha
/archives/xfs/2008-08/msg00648.html (9,568 bytes)

8. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: xx>
Date: Wed, 13 Aug 2008 10:58:52 +1000
That's the mm code calling fput() with the mmap_sem held. That's a problem in the VM code, which XFS can do nothing about. The normal I/O paths always lock the inode first, then (if a page fault occu
/archives/xfs/2008-08/msg00651.html (10,604 bytes)

9. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: xx>
Date: Wed, 13 Aug 2008 15:05:13 -0700
Dave Chinner wrote: Once again, "a problem with the generic code inverting the normal lock order". This one cannot deadlock, though, because by definition any inode on the unused list is, well, unuse
/archives/xfs/2008-08/msg00670.html (11,025 bytes)

10. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: xx>
Date: Thu, 14 Aug 2008 10:41:01 +1000
generic code == non-filesystem specific kernel code that interfaces with the filesystem code. Any filesystem that does memory allocation with the same type of lock held that it might take when reclai
/archives/xfs/2008-08/msg00673.html (12,314 bytes)

11. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: xx>
Date: Wed, 13 Aug 2008 18:04:16 -0700
Dave Chinner wrote: I've asked the lockdep ppl to treat stuff like memory reclaim and the iprune_mutex specially because of this recursive calling nature of memory reclaim, but so far nothing has hap
/archives/xfs/2008-08/msg00676.html (11,099 bytes)

12. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: xx>
Date: Thu, 14 Aug 2008 12:01:11 +1000
None of those applications use the swap extents code in XFS, so if they are reporting problems related to xfs_fsr, then it's the xfs_fsr locking that is triggering these later problems. Fixing the sw
/archives/xfs/2008-08/msg00677.html (12,288 bytes)

13. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: "Linda A. Walsh" <xfs@xxxxxxxxx>
Date: Tue, 12 Aug 2008 15:28:46 -0700
Eric Sandeen wrote: ... Is it also known, (and the same bug) when you get the lock warnings when doing "xfs_restore", as well (dio_get_page and xfs_ilock)... Doesn't give me the warm & fuzzies, but I
/archives/xfs/2008-08/msg01096.html (9,833 bytes)

14. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 13 Aug 2008 10:58:52 +1000
That's the mm code calling fput() with the mmap_sem held. That's a problem in the VM code, which XFS can do nothing about. The normal I/O paths always lock the inode first, then (if a page fault occu
/archives/xfs/2008-08/msg01099.html (10,746 bytes)

15. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: Linda Walsh <xfs@xxxxxxxxx>
Date: Wed, 13 Aug 2008 15:05:13 -0700
This one cannot deadlock, though, because by definition any inode on the unused list is, well, unused and hence we can't be holding a reference to it... -- This is great, maybe...but what do you mean
/archives/xfs/2008-08/msg01118.html (11,031 bytes)

16. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 14 Aug 2008 10:41:01 +1000
generic code == non-filesystem specific kernel code that interfaces with the filesystem code. Any filesystem that does memory allocation with the same type of lock held that it might take when reclai
/archives/xfs/2008-08/msg01121.html (12,537 bytes)

17. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: Linda Walsh <xfs@xxxxxxxxx>
Date: Wed, 13 Aug 2008 18:04:16 -0700
Dave Chinner wrote: I've asked the lockdep ppl to treat stuff like memory reclaim and the iprune_mutex specially because of this recursive calling nature of memory reclaim, but so far nothing has hap
/archives/xfs/2008-08/msg01124.html (11,246 bytes)

18. Re: XFS Lock debugging noise or real problem? (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 14 Aug 2008 12:01:11 +1000
None of those applications use the swap extents code in XFS, so if they are reporting problems related to xfs_fsr, then it's the xfs_fsr locking that is triggering these later problems. Fixing the sw
/archives/xfs/2008-08/msg01125.html (12,592 bytes)


This search system is powered by Namazu