On Wed, 27 Sep 2006 00:16:31 +0900 (JST), Atsushi Nemoto <anemo@xxxxxxxxxxxxx> 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:
--- snip ---
Mounting remote filesystems...
=======================================================
[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
mount/1383 is trying to acquire lock:
(&mm->mmap_sem){----}, at: [<80032370>] do_page_fault+0xf0/0x3e0
but task is already holding lock:
(sk_lock-AF_INET){--..}, at: [<802a55ac>] 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){--..}:
[<80075ac0>] __lock_acquire+0xd7c/0xe98
[<80076098>] lock_acquire+0xa4/0xf8
[<8026a9ec>] lock_sock+0xec/0x11c
[<802be8cc>] udp_sendmsg+0x20c/0x5cc
[<802c772c>] inet_sendmsg+0x58/0x9c
[<80267270>] sock_sendmsg+0xb0/0x104
[<802672f0>] kernel_sendmsg+0x2c/0x48
[<802e9924>] xs_udp_send_request+0x1d8/0x354
[<802e65dc>] xprt_transmit+0x70/0x284
[<802e3140>] call_transmit+0x204/0x2e4
[<802eb16c>] __rpc_execute+0xa8/0x2bc
[<802eb3e8>] rpc_execute+0x40/0x54
[<8013434c>] nfs_execute_read+0x50/0x84
[<80134c60>] nfs_pagein_one+0x2e4/0x388
[<80134e18>] nfs_readpages+0x114/0x21c
[<8008ce7c>] __do_page_cache_readahead+0x214/0x33c
[<8008d550>] do_page_cache_readahead+0x6c/0x9c
[<80087498>] filemap_nopage+0x178/0x560
[<800953e4>] __handle_mm_fault+0x178/0xb70
[<80032504>] do_page_fault+0x284/0x3e0
[<80025d00>] ret_from_exception+0x0/0x10
[<80189af4>] __bzero+0x38/0x80
[<800e5554>] padzero+0x6c/0x8c
[<800e6eb8>] load_elf_binary+0x878/0x16d0
[<800b8b08>] search_binary_handler+0xf8/0x450
[<800baa90>] do_execve+0x13c/0x224
[<8002b904>] sys_execve+0x54/0x88
[<80030cc0>] stack_done+0x20/0x3c
-> #0 (&mm->mmap_sem){----}:
[<80075960>] __lock_acquire+0xc1c/0xe98
[<80076098>] lock_acquire+0xa4/0xf8
[<80070bb0>] down_read+0x38/0x58
[<80032370>] do_page_fault+0xf0/0x3e0
[<80025d00>] ret_from_exception+0x0/0x10
[<8018910c>] both_aligned+0x2c/0x64
[<802712b4>] memcpy_toiovec+0x8c/0xbc
[<80271d74>] skb_copy_datagram_iovec+0x208/0x2a4
[<802a5bdc>] tcp_recvmsg+0x674/0x920
[<80269e5c>] sock_common_recvmsg+0x4c/0x70
[<80266a58>] do_sock_read+0xb0/0xd8
[<80267668>] sock_aio_read+0x80/0x88
[<800a8bfc>] do_sync_read+0xe4/0x14c
[<800a99f4>] vfs_read+0x1a8/0x1b0
[<800a9f9c>] sys_read+0x5c/0xb0
[<80030cc0>] stack_done+0x20/0x3c
other info that might help us debug this:
1 lock held by mount/1383:
#0: (sk_lock-AF_INET){--..}, at: [<802a55ac>] tcp_recvmsg+0x44/0x920
stack backtrace:
Call Trace:
[<8002de48>] dump_stack+0x10/0x44
[<80074d28>] print_circular_bug_tail+0x70/0x8c
[<80075960>] __lock_acquire+0xc1c/0xe98
[<80076098>] lock_acquire+0xa4/0xf8
[<80070bb0>] down_read+0x38/0x58
[<80032370>] do_page_fault+0xf0/0x3e0
[<80025d00>] ret_from_exception+0x0/0x10
--- snip ---
Does this output say socket I/O and a page-fault on NFS can cause a
deadlock?
---
Atsushi Nemoto
