Messages in this thread | | | Date | Thu, 13 Jul 2006 00:07:16 -0400 | From | Dave Jones <> | Subject | another networking lockdep bug |
| |
Not sure if this one got reported/fixed yet, as I was running a kernel from sometime last week..
Dave
======================================================= [ INFO: possible circular locking dependency detected ] ------------------------------------------------------- git-fetch/11540 is trying to acquire lock: (sk_lock-AF_INET){--..}, at: [<ffffffff80228062>] tcp_sendmsg+0x1f/0xb1a
but task is already holding lock: (&inode->i_alloc_sem){--..}, at: [<ffffffff8022f765>] notify_change+0x105/0x2f7
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&inode->i_alloc_sem){--..}: [<ffffffff802ab792>] lock_acquire+0x4a/0x69 [<ffffffff802a831c>] down_write+0x3a/0x47 [<ffffffff8022f764>] notify_change+0x104/0x2f7 [<ffffffff802e00c7>] do_truncate+0x52/0x72 [<ffffffff80212d17>] may_open+0x1d5/0x231 [<ffffffff8021c270>] open_namei+0x290/0x6b4 [<ffffffff80229974>] do_filp_open+0x27/0x46 [<ffffffff8021acb7>] do_sys_open+0x4e/0xcd [<ffffffff80234b2a>] sys_open+0x1a/0x1d [<ffffffff80262e4d>] system_call+0x7d/0x83
-> #2 (&sysfs_inode_imutex_key){--..}: [<ffffffff802ab792>] lock_acquire+0x4a/0x69 [<ffffffff802691c2>] __mutex_lock_slowpath+0xeb/0x29f [<ffffffff8026939f>] mutex_lock+0x29/0x2e [<ffffffff8030ed74>] create_dir+0x2c/0x1e2 [<ffffffff8030f32f>] sysfs_create_dir+0x59/0x78 [<ffffffff8034cbd6>] kobject_add+0x114/0x1d8 [<ffffffff803baa5d>] class_device_add+0xb5/0x49d [<ffffffff8042f982>] netdev_register_sysfs+0x98/0xa2 [<ffffffff8042685f>] register_netdevice+0x28c/0x377 [<ffffffff804269a4>] register_netdev+0x5a/0x69 [<ffffffff8098a9f8>] loopback_init+0x4e/0x53 [<ffffffff8098a8fe>] net_olddevs_init+0xb/0xb7 [<ffffffff802709c0>] init+0x177/0x348 [<ffffffff80263d9d>] child_rip+0x7/0x12
-> #1 (rtnl_mutex){--..}: [<ffffffff802ab792>] lock_acquire+0x4a/0x69 [<ffffffff802691c2>] __mutex_lock_slowpath+0xeb/0x29f [<ffffffff8026939f>] mutex_lock+0x29/0x2e [<ffffffff8042d973>] rtnl_lock+0xf/0x12 [<ffffffff8045c18a>] ip_mc_leave_group+0x1e/0xae [<ffffffff80446087>] do_ip_setsockopt+0x6ad/0x9b2 [<ffffffff8044643a>] ip_setsockopt+0x2a/0x84 [<ffffffff80454328>] udp_setsockopt+0xd/0x1c [<ffffffff8041f094>] sock_common_setsockopt+0xe/0x11 [<ffffffff8041e20f>] sys_setsockopt+0x8e/0xb4 [<ffffffff80262fd9>] tracesys+0xd0/0xdb
-> #0 (sk_lock-AF_INET){--..}: [<ffffffff802ab792>] lock_acquire+0x4a/0x69 [<ffffffff8023726c>] lock_sock+0xd4/0xe7 [<ffffffff80228061>] tcp_sendmsg+0x1e/0xb1a [<ffffffff80248ff8>] inet_sendmsg+0x45/0x53 [<ffffffff80259dd3>] sock_sendmsg+0x110/0x130 [<ffffffff8041ed0c>] kernel_sendmsg+0x3c/0x52 [<ffffffff8853c9e9>] xs_tcp_send_request+0x117/0x320 [sunrpc] [<ffffffff8853b8d5>] xprt_transmit+0x105/0x21e [sunrpc] [<ffffffff8853a71e>] call_transmit+0x1f4/0x239 [sunrpc] [<ffffffff8853f06e>] __rpc_execute+0x9b/0x1e6 [sunrpc] [<ffffffff8853f1de>] rpc_execute+0x1a/0x1d [sunrpc] [<ffffffff885394ad>] rpc_call_sync+0x87/0xb9 [sunrpc] [<ffffffff885a5587>] nfs3_rpc_wrapper+0x2e/0x74 [nfs] [<ffffffff885a5870>] nfs3_proc_setattr+0x9b/0xd3 [nfs] [<ffffffff8859bffb>] nfs_setattr+0xe9/0x11e [nfs] [<ffffffff8022f7b4>] notify_change+0x154/0x2f7 [<ffffffff802e00c7>] do_truncate+0x52/0x72 [<ffffffff80212d17>] may_open+0x1d5/0x231 [<ffffffff8021c270>] open_namei+0x290/0x6b4 [<ffffffff80229974>] do_filp_open+0x27/0x46 [<ffffffff8021acb7>] do_sys_open+0x4e/0xcd [<ffffffff80234b2a>] sys_open+0x1a/0x1d [<ffffffff80262fd9>] tracesys+0xd0/0xdb
other info that might help us debug this:
2 locks held by git-fetch/11540: #0: (&inode->i_mutex){--..}, at: [<ffffffff802693a0>] mutex_lock+0x2a/0x2e #1: (&inode->i_alloc_sem){--..}, at: [<ffffffff8022f765>] notify_change+0x105/0x2f7
stack backtrace:
Call Trace: [<ffffffff802719b8>] show_trace+0xaa/0x23d [<ffffffff80271b60>] dump_stack+0x15/0x17 [<ffffffff802a99ec>] print_circular_bug_tail+0x6c/0x77 [<ffffffff802aaff1>] __lock_acquire+0x853/0xa54 [<ffffffff802ab793>] lock_acquire+0x4b/0x69 [<ffffffff8023726d>] lock_sock+0xd5/0xe7 [<ffffffff80228062>] tcp_sendmsg+0x1f/0xb1a [<ffffffff80248ff9>] inet_sendmsg+0x46/0x53 [<ffffffff80259dd4>] sock_sendmsg+0x111/0x130 [<ffffffff8041ed0d>] kernel_sendmsg+0x3d/0x52 [<ffffffff8853c9ea>] :sunrpc:xs_tcp_send_request+0x118/0x320 [<ffffffff8853b8d6>] :sunrpc:xprt_transmit+0x106/0x21e [<ffffffff8853a71f>] :sunrpc:call_transmit+0x1f5/0x239 [<ffffffff8853f06f>] :sunrpc:__rpc_execute+0x9c/0x1e6 [<ffffffff8853f1df>] :sunrpc:rpc_execute+0x1b/0x1d [<ffffffff885394ae>] :sunrpc:rpc_call_sync+0x88/0xb9 [<ffffffff885a5588>] :nfs:nfs3_rpc_wrapper+0x2f/0x74 [<ffffffff885a5871>] :nfs:nfs3_proc_setattr+0x9c/0xd3 [<ffffffff8859bffc>] :nfs:nfs_setattr+0xea/0x11e [<ffffffff8022f7b5>] notify_change+0x155/0x2f7 [<ffffffff802e00c8>] do_truncate+0x53/0x72 [<ffffffff80212d18>] may_open+0x1d6/0x231 [<ffffffff8021c271>] open_namei+0x291/0x6b4 [<ffffffff80229975>] do_filp_open+0x28/0x46 [<ffffffff8021acb8>] do_sys_open+0x4f/0xcd [<ffffffff80234b2b>] sys_open+0x1b/0x1d [<ffffffff80262fda>] tracesys+0xd1/0xdb
-- http://www.codemonkey.org.uk - 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/
| |