On Mon, 2005-01-10 at 10:59 -0600, Dave Kleikamp wrote:
> This thread must be in diUpdatePMap, trying to acquire ipimap's
> rdwrlock: IREAD_LOCK(). The funny thing is that the only place a write
> lock is taken on this inode is in diNewIAG, which is only called under
> diAlloc, which I don't see in any stacks.
>
> I can't find any error path that would leave the lock taken, so I can't
> account for why this thread would be blocked. I'm sure you would have
> noticed if a thread oopsed in this path, leaving the lock locked.
I found the deadlock. This thread is the missing link:
fstest D C0348640 0 4598 4561 4599 4597 (NOTLB)
dbc11d88 00000086 dbd57770 c0348640 00000000 00000000 00000000 00000000
00000000 df1ed83c d9912d50 00000000 d8dc7700 000f424a dbd57918
df7dd244
00000286 dbc10000 dbd57770 c026d7d7 df7dd24c 00000001 dbd57770
c0118714
Call Trace:
[<c026d7d7>] __down+0x8b/0xfd
[<c0118714>] default_wake_function+0x0/0x12
[<c026d984>] __down_failed+0x8/0xc
[<e0970663>] .text.lock.jfs_imap+0x205/0x422 [jfs]
[<c0169722>] alloc_inode+0xf2/0x19b
[<e097bccb>] ialloc+0x5b/0x1b0 [jfs]
[<e096399d>] jfs_mkdir+0x5d/0x2f0 [jfs]
[<c0117c03>] recalc_task_prio+0x93/0x188
[<c015dce7>] permission+0x67/0x79
[<c015eeca>] link_path_walk+0xccf/0xdb2
[<c015de3d>] cached_lookup+0x23/0x85
[<c015dce7>] permission+0x67/0x79
[<c0160379>] vfs_mkdir+0xad/0x137
[<c01604ba>] sys_mkdir+0xb7/0xf6
[<c01181fd>] schedule_tail+0x41/0x4d
[<c0105dfd>] sysenter_past_esp+0x52/0x71
The compiler does a lot of inlining, but I do believe this is in
diNewIAG. The thread is doing a down(&JFS_IP(ipimap)->commit_sem) while
holding the rdwr_lock (which is a recent change). I will have to see
how hard this is to fix.
--
David Kleikamp
IBM Linux Technology Center
_______________________________________________
Jfs-discussion mailing list
[email protected]
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
