Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[LOCKDEP\]\s+xfs\:\s+possible\s+recursive\s+locking\s+detected\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[LOCKDEP\]\s+xfs\:\s+possible\s+recursive\s+locking\s+detected\s*$/: 48 ]

Total 48 documents matching your query.

1. [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Alexey Dobriyan <adobriyan@xxxxxxxxx>; Date: Tue, 4 Jul 2006 04:41:16 +0400; 2.6.17-912b2539e1e062cec73e2e61448e507f7719bd08 While trying to remove 2 small files, 2 empty dirs and 1 empty dir on xfs partition == [ INFO: possible recursive locking detected ] -- rm/7596 is tryi; /archives/xfs/2006-07/msg00004.html (10,171 bytes)
2. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Nathan Scott <nathans@xxxxxxx>; Date: Tue, 4 Jul 2006 11:25:03 +1000; Hmm... they'd be different inodes though, so different lock addresses in memory - is lockdep taking that into account? Would we need to go annotate xfs_ilock somehow to give better hints to the lockd; /archives/xfs/2006-07/msg00005.html (10,073 bytes)
3. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Matthew Wilcox <matthew@xxxxxx>; Date: Mon, 3 Jul 2006 19:18:58 -0600; Probably spurious. xfs_ilock can be called on both the parent and child, which wouldn't be a deadlock.; /archives/xfs/2006-07/msg00008.html (11,302 bytes)
4. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Nathan Scott <nathans@xxxxxxx>; Date: Tue, 4 Jul 2006 16:56:05 +1000; Yep, looks like its really easy to trigger - I pulled Linus' tree, enabled everything I could see that looked lockdep related and I immediately saw warnings during bootup... that was with an XFS root; /archives/xfs/2006-07/msg00011.html (11,484 bytes)
5. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Ingo Molnar <mingo@xxxxxxx>; Date: Tue, 4 Jul 2006 10:41:43 +0200; the patch below should solve the case mentioned above, but i'm sure there will be other cases as well. XFS locking seems quite complex all around. All this dynamic flag-passing into an opaque functio; /archives/xfs/2006-07/msg00012.html (17,359 bytes)
6. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Nathan Scott <nathans@xxxxxxx>; Date: Tue, 4 Jul 2006 19:11:00 +1000; Thanks Ingo! I'll run with this for awhile and see if I can find any other issues. Mhmm. Right... but that leaves plenty that don't, and they're not simple to change. There are generic routines that; /archives/xfs/2006-07/msg00013.html (12,730 bytes)
7. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Ingo Molnar <mingo@xxxxxxx>; Date: Tue, 4 Jul 2006 11:12:47 +0200; do you have anything in there that spinlock/mutex debugging or lockdep does not catch? If yes then i'll add it to the generic lock debugging code. Ingo; /archives/xfs/2006-07/msg00014.html (11,145 bytes)
8. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Ingo Molnar <mingo@xxxxxxx>; Date: Tue, 4 Jul 2006 11:57:43 +0200; the main variation in xfs_iget() is whether we lock the inode read-write, read-only or not at all, correct? (XFS_ILOCK_EXCL, XFS_ILOCK_SHARED and 0) That could be cleaned up the following way: - rena; /archives/xfs/2006-07/msg00015.html (12,490 bytes)
9. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Ingo Molnar <mingo@xxxxxxx>; Date: Tue, 4 Jul 2006 15:03:38 +0200; another thing: i have added real 'lock allocation debugging' (CONFIG_DEBUG_LOCK_ALLOC) to the kernel, which covers spinlocks, rwlocks, mutexes and rw-semaphores. It does the following: This feature w; /archives/xfs/2006-07/msg00017.html (11,182 bytes)
10. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Andi Kleen <ak@xxxxxxx>; Date: 04 Jul 2006 14:42:42 +0200; Isn't that obsolete now with lockdep? -Andi; /archives/xfs/2006-07/msg00019.html (10,063 bytes)
11. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Nathan Scott <nathans@xxxxxxx>; Date: Wed, 5 Jul 2006 13:23:29 +1000; The thing we're catching automatically there is potential ordering violations on the XFS inode iolock vs ilock. I don't know if the other methods can help us there too or not. cheers. -- Nathan; /archives/xfs/2006-07/msg00033.html (11,280 bytes)
12. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Nathan Scott <nathans@xxxxxxx>; Date: Wed, 5 Jul 2006 13:37:42 +1000; *nod*. One difficulty is that xfs_iget_core would also need this treatment (the lock_mode parameter is passed down there), and we may end up be with quite a few functions and/or duplicated code. But; /archives/xfs/2006-07/msg00034.html (11,625 bytes)
13. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Nathan Scott <nathans@xxxxxxx>; Date: Wed, 5 Jul 2006 15:26:52 +1000; Hmm, don't think so - only if you needed to change all other spinlock uses in the kernel to have a teardown too? Can't see that in current git trees, anyway, so I expect that to be OK as is. cheers.; /archives/xfs/2006-07/msg00035.html (11,210 bytes)
14. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Arjan van de Ven <arjan@xxxxxxxxxxxxx>; Date: Wed, 05 Jul 2006 06:44:50 +0200; lockdep will catch those just fine.; /archives/xfs/2006-07/msg00036.html (11,372 bytes)
15. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Ingo Molnar <mingo@xxxxxxx>; Date: Wed, 5 Jul 2006 08:46:51 +0200; i should have formulated this as a question: should i implement spin_lock_destroy()? A few months ago i implemented mutex_destroy() for XFS's use, and now we could do it for spinlocks too. Right now; /archives/xfs/2006-07/msg00037.html (11,886 bytes)
16. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Nathan Scott <nathans@xxxxxxx>; Date: Wed, 5 Jul 2006 16:58:24 +1000; Oh, right, I see - yes, I think that could be generally useful and we'd get some value out of that in XFS for sure. Thanks. cheers. -- Nathan; /archives/xfs/2006-07/msg00038.html (11,348 bytes)
17. [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Alexey Dobriyan <adobriyan@xxxxxxxxx>; Date: Tue, 4 Jul 2006 04:41:16 +0400; 2.6.17-912b2539e1e062cec73e2e61448e507f7719bd08 While trying to remove 2 small files, 2 empty dirs and 1 empty dir on xfs partition == [ INFO: possible recursive locking detected ] -- rm/7596 is tryi; /archives/xfs/2006-07/msg00394.html (10,171 bytes)
18. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Nathan Scott <nathans@xxxxxxx>; Date: Tue, 4 Jul 2006 11:25:03 +1000; Hmm... they'd be different inodes though, so different lock addresses in memory - is lockdep taking that into account? Would we need to go annotate xfs_ilock somehow to give better hints to the lockd; /archives/xfs/2006-07/msg00395.html (10,073 bytes)
19. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Matthew Wilcox <matthew@xxxxxx>; Date: Mon, 3 Jul 2006 19:18:58 -0600; Probably spurious. xfs_ilock can be called on both the parent and child, which wouldn't be a deadlock.; /archives/xfs/2006-07/msg00398.html (11,302 bytes)
20. Re: [LOCKDEP] xfs: possible recursive locking detected (score: 1): Author: Nathan Scott <nathans@xxxxxxx>; Date: Tue, 4 Jul 2006 16:56:05 +1000; Yep, looks like its really easy to trigger - I pulled Linus' tree, enabled everything I could see that looked lockdep related and I immediately saw warnings during bootup... that was with an XFS root; /archives/xfs/2006-07/msg00401.html (11,484 bytes)

Current List: 1 - 20
Page: [1] [2] [3]