Messages in this thread |  | | | Subject | 2.6.18 - possible recursive locking detected (NFS/networking related?) | | From | Anton Altaparmakov <> | | Date | Fri, 22 Sep 2006 08:07:12 +0100 |
I have my home directory on NFS and got this running 2.6.18 (vanilla) kernel:
======================================================= [ INFO: possible circular locking dependency detected ] ------------------------------------------------------- bash/4354 is trying to acquire lock: (&inode->i_data.tree_lock){++..}, at: [<c103f991>] find_get_page+0x10/0x45 but task is already holding lock: (&inode->i_mutex){--..}, at: [<c145c8a6>] mutex_lock+0x19/0x20 which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&inode->i_alloc_sem){--..}: [<c1031cc6>] lock_acquire+0x56/0x73 [<c102ec03>] down_write+0x27/0x42 [<c107341d>] notify_change+0xe9/0x278 [<c105ac14>] do_truncate+0x58/0x73 [<c10690a3>] may_open+0x1bd/0x20d [<c106b0ca>] open_namei+0x26e/0x61a [<c105a917>] do_filp_open+0x22/0x39 [<c105a96e>] do_sys_open+0x40/0xba [<c105aa11>] sys_open+0x13/0x15 [<c1002b25>] sysenter_past_esp+0x56/0x8d -> #2 (&sysfs_inode_imutex_key){--..}: [<c1031cc6>] lock_acquire+0x56/0x73 [<c145c71e>] __mutex_lock_slowpath+0xaf/0x21e [<c145c8a6>] mutex_lock+0x19/0x20 [<c1096238>] create_dir+0x1e/0x1a5 [<c1096aa5>] sysfs_create_dir+0x49/0x64 [<c121ec65>] kobject_add+0xcd/0x17f [<c12afcc4>] class_device_add+0x9d/0x3e2 [<c13b5536>] netdev_register_sysfs+0x75/0x7d [<c13ab32d>] register_netdevice+0x22b/0x2e5 [<c13ac488>] register_netdev+0x5d/0x6e [<c12c3789>] e1000_probe+0xa68/0xb2e [<c1237289>] pci_device_probe+0x3a/0x61 [<c12aeff3>] driver_probe_device+0x46/0x94 [<c12af115>] __driver_attach+0x5a/0x89 [<c12aea51>] bus_for_each_dev+0x45/0x6c [<c12aef45>] driver_attach+0x16/0x1b [<c12ae6ce>] bus_add_driver+0x69/0x110 [<c12af3bc>] driver_register+0x7a/0x7f [<c12373f3>] __pci_register_driver+0x55/0x77 [<c18373bd>] e1000_init_module+0x32/0x34 [<c10003ef>] init+0x11f/0x29d [<c1000bf1>] kernel_thread_helper+0x5/0xb -> #1 (rtnl_mutex){--..}: [<c1031cc6>] lock_acquire+0x56/0x73 [<c145c71e>] __mutex_lock_slowpath+0xaf/0x21e [<c145c8a6>] mutex_lock+0x19/0x20 [<c13b327d>] rtnl_lock+0xd/0xf [<c13f0231>] ip_mc_join_group+0x2b/0xd8 [<c13d0e18>] ip_setsockopt+0x623/0x95e [<c13e7197>] udp_setsockopt+0x23/0xa1 [<c13a42d6>] sock_common_setsockopt+0x1c/0x1e [<c13a30f1>] sys_setsockopt+0x57/0x76 [<c13a3ef1>] sys_socketcall+0x130/0x16b [<c1002b25>] sysenter_past_esp+0x56/0x8d -> #0 (&inode->i_data.tree_lock){++..}: [<c1031cc6>] lock_acquire+0x56/0x73 [<c13a4998>] lock_sock+0xbc/0xcc [<c13d4b75>] tcp_sendmsg+0x14/0xa15 [<c13ed10d>] inet_sendmsg+0x34/0x40 [<c13a2746>] sock_sendmsg+0xcf/0xe7 [<c13a3f5c>] kernel_sendmsg+0x30/0x40 [<c142b1dc>] xs_tcp_send_request+0x106/0x2f9 [<c142a395>] xprt_transmit+0xcc/0x1b4 [<c14283f6>] call_transmit+0x1af/0x1dc [<c142d36d>] __rpc_execute+0x7c/0x199 [<c142d4ae>] rpc_execute+0x17/0x19 [<c1428567>] rpc_call_sync+0x75/0x9e [<c110b76e>] nfs3_rpc_wrapper+0x26/0x68 [<c110ba37>] nfs3_proc_setattr+0xab/0xde [<c1103011>] nfs_setattr+0x111/0x139 [<c1073435>] notify_change+0x101/0x278 [<c105ac14>] do_truncate+0x58/0x73 [<c10690a3>] may_open+0x1bd/0x20d [<c106b0ca>] open_namei+0x26e/0x61a [<c105a917>] do_filp_open+0x22/0x39 [<c105a96e>] do_sys_open+0x40/0xba [<c105aa11>] sys_open+0x13/0x15 [<c1002b25>] sysenter_past_esp+0x56/0x8d other info that might help us debug this:
2 locks held by bash/4354: #0: (&inode->i_mutex){--..}, at: [<c145c8a6>] mutex_lock+0x19/0x20 #1: (&inode->i_alloc_sem){--..}, at: [<c107341d>] notify_change+0xe9/0x278 stack backtrace: [<c1003cc8>] show_trace_log_lvl+0x57/0x16f [<c10042f1>] show_trace+0x16/0x19 [<c10043b9>] dump_stack+0x1a/0x1f [<c103103c>] print_circular_bug_tail+0x59/0x64 [<c1031872>] __lock_acquire+0x82b/0x9b6 [<c1031cc6>] lock_acquire+0x56/0x73 [<c13a4998>] lock_sock+0xbc/0xcc [<c13d4b75>] tcp_sendmsg+0x14/0xa15 [<c13ed10d>] inet_sendmsg+0x34/0x40 [<c13a2746>] sock_sendmsg+0xcf/0xe7 [<c13a3f5c>] kernel_sendmsg+0x30/0x40 [<c142b1dc>] xs_tcp_send_request+0x106/0x2f9 [<c142a395>] xprt_transmit+0xcc/0x1b4 [<c14283f6>] call_transmit+0x1af/0x1dc [<c142d36d>] __rpc_execute+0x7c/0x199 [<c142d4ae>] rpc_execute+0x17/0x19 [<c1428567>] rpc_call_sync+0x75/0x9e [<c110b76e>] nfs3_rpc_wrapper+0x26/0x68 [<c110ba37>] nfs3_proc_setattr+0xab/0xde [<c1103011>] nfs_setattr+0x111/0x139 [<c1073435>] notify_change+0x101/0x278 [<c105ac14>] do_truncate+0x58/0x73 [<c10690a3>] may_open+0x1bd/0x20d [<c106b0ca>] open_namei+0x26e/0x61a [<c105a917>] do_filp_open+0x22/0x39 [<c105a96e>] do_sys_open+0x40/0xba [<c105aa11>] sys_open+0x13/0x15 [<c1002b25>] sysenter_past_esp+0x56/0x8d DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x8d Leftover inexact backtrace: [<c10042f1>] show_trace+0x16/0x19 [<c10043b9>] dump_stack+0x1a/0x1f [<c103103c>] print_circular_bug_tail+0x59/0x64 [<c1031872>] __lock_acquire+0x82b/0x9b6 [<c1031cc6>] lock_acquire+0x56/0x73 [<c13a4998>] lock_sock+0xbc/0xcc [<c13d4b75>] tcp_sendmsg+0x14/0xa15 [<c13ed10d>] inet_sendmsg+0x34/0x40 [<c13a2746>] sock_sendmsg+0xcf/0xe7 [<c13a3f5c>] kernel_sendmsg+0x30/0x40 [<c142b1dc>] xs_tcp_send_request+0x106/0x2f9 [<c142a395>] xprt_transmit+0xcc/0x1b4 [<c14283f6>] call_transmit+0x1af/0x1dc [<c142d36d>] __rpc_execute+0x7c/0x199 [<c142d4ae>] rpc_execute+0x17/0x19 [<c1428567>] rpc_call_sync+0x75/0x9e [<c110b76e>] nfs3_rpc_wrapper+0x26/0x68 [<c110ba37>] nfs3_proc_setattr+0xab/0xde [<c1103011>] nfs_setattr+0x111/0x139 [<c1073435>] notify_change+0x101/0x278 [<c105ac14>] do_truncate+0x58/0x73 [<c10690a3>] may_open+0x1bd/0x20d [<c106b0ca>] open_namei+0x26e/0x61a [<c105a917>] do_filp_open+0x22/0x39 [<c105a96e>] do_sys_open+0x40/0xba [<c105aa11>] sys_open+0x13/0x15 [<c1002b25>] sysenter_past_esp+0x56/0x8d
Best regards,
Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://www.linux-ntfs.org/ & http://www-stu.christs.cam.ac.uk/~aia21/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |