On Thu, 28 Sep 2006 11:42:47 +0100, Ralf Baechle <ralf@xxxxxxxxxxxxxx> wrote:
> > > And I got this output when I booted kernel 2.6.18 using nfsroot:
> >
> > With updated stacktrace (now it shows all kernel context), I got:
>
> Thanks. Now the lockdep output makes sense. At a glance it also looks
> like this case isn't a false positive ...
And here is a updated lockdep output with "nfsroot=host:dir,tcp"
option. In previous output, I used NFS over TCP but not specified
",tcp" on nfsroot.
Also I found this happens only NFS over TCP on Debian 3.1 (sarge). If
I used NFS over UDP or Debian 4.0 (etch), lockdep does not show
anything. I can not tell why the version of Debian affect this...
--- snip ---
Mounting remote filesystems...
=======================================================
[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
mount/1425 is trying to acquire lock:
(&mm->mmap_sem){----}, at: [<80031b70>] do_page_fault+0xf0/0x3c0
but task is already holding lock:
(sk_lock-AF_INET){--..}, at: [<802a7170>] tcp_recvmsg+0x44/0x920
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (sk_lock-AF_INET){--..}:
[<8007383c>] __lock_acquire+0xd80/0xe9c
[<80073e14>] lock_acquire+0xa4/0xf8
[<8026bc98>] lock_sock+0xec/0x11c
[<802a62f8>] tcp_sendmsg+0x40/0xc60
[<802c9194>] inet_sendmsg+0x58/0x9c
[<8026858c>] sock_sendmsg+0xb0/0x104
[<8026860c>] kernel_sendmsg+0x2c/0x48
[<802ebd70>] xs_tcp_send_request+0x134/0x3f8
[<802ea408>] xprt_transmit+0x70/0x284
[<802e70b0>] call_transmit+0x1fc/0x2dc
[<802ef194>] __rpc_execute+0xa8/0x2bc
[<802ef410>] rpc_execute+0x40/0x54
[<8013411c>] nfs_execute_read+0x50/0x84
[<80134a64>] nfs_pagein_one+0x2e4/0x388
[<80134ec0>] nfs_readpages+0x128/0x230
[<8008a2b4>] __do_page_cache_readahead+0x20c/0x328
[<8008a97c>] do_page_cache_readahead+0x6c/0x9c
[<800848e8>] filemap_nopage+0x17c/0x564
[<8009285c>] __handle_mm_fault+0x178/0xc18
[<80031d00>] do_page_fault+0x280/0x3c0
[<80025c00>] ret_from_exception+0x0/0x10
[<8018b7b4>] __bzero+0x38/0x80
[<800e2e24>] padzero+0x6c/0x8c
[<800e4864>] load_elf_binary+0x8ac/0x16e8
[<800b61c8>] search_binary_handler+0xe8/0x420
[<800b805c>] do_execve+0x13c/0x224
[<8002b554>] sys_execve+0x54/0x88
[<80030780>] stack_done+0x20/0x3c
-> #0 (&mm->mmap_sem){----}:
[<800736dc>] __lock_acquire+0xc20/0xe9c
[<80073e14>] lock_acquire+0xa4/0xf8
[<8006e930>] down_read+0x38/0x58
[<80031b70>] do_page_fault+0xf0/0x3c0
[<80025c00>] ret_from_exception+0x0/0x10
[<8018adcc>] both_aligned+0x2c/0x64
[<80272504>] memcpy_toiovec+0x8c/0xbc
[<80272fc4>] skb_copy_datagram_iovec+0x208/0x2a4
[<802a77a0>] tcp_recvmsg+0x674/0x920
[<8026b0dc>] sock_common_recvmsg+0x4c/0x70
[<80267a88>] do_sock_read+0xb0/0xd8
[<80268984>] sock_aio_read+0x80/0x88
[<800a633c>] do_sync_read+0xe4/0x14c
[<800a7134>] vfs_read+0x1a8/0x1b0
[<800a76e0>] sys_read+0x5c/0xb0
[<80030780>] stack_done+0x20/0x3c
other info that might help us debug this:
1 lock held by mount/1425:
#0: (sk_lock-AF_INET){--..}, at: [<802a7170>] tcp_recvmsg+0x44/0x920
stack backtrace:
Call Trace:
[<8002da54>] dump_stack+0x10/0x44
[<80072aa0>] print_circular_bug_tail+0x70/0x8c
[<800736dc>] __lock_acquire+0xc20/0xe9c
[<80073e14>] lock_acquire+0xa4/0xf8
[<8006e930>] down_read+0x38/0x58
[<80031b70>] do_page_fault+0xf0/0x3c0
[<80025c00>] ret_from_exception+0x0/0x10
[<8018adcc>] both_aligned+0x2c/0x64
[<80272504>] memcpy_toiovec+0x8c/0xbc
[<80272fc4>] skb_copy_datagram_iovec+0x208/0x2a4
[<802a77a0>] tcp_recvmsg+0x674/0x920
[<8026b0dc>] sock_common_recvmsg+0x4c/0x70
[<80267a88>] do_sock_read+0xb0/0xd8
[<80268984>] sock_aio_read+0x80/0x88
[<800a633c>] do_sync_read+0xe4/0x14c
[<800a7134>] vfs_read+0x1a8/0x1b0
[<800a76e0>] sys_read+0x5c/0xb0
[<80030780>] stack_done+0x20/0x3c
--- snip ---
Any idea?
---
Atsushi Nemoto
