Red Hat Bugzilla – Bug 205487
circular dependency reported by lockdep (slock-AF_INET6)
Last modified: 2015-01-04 17:28:30 EST
Description of problem: I found the following in /var/log/messages after light work on a rawhide machine: ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.17-1.2617.2.1.fc6 #1 ------------------------------------------------------- less/9806 is trying to acquire lock: (sk_lock-AF_INET){--..}, at: [<ffffffff80227700>] tcp_sendmsg+0x1f/0xb1d but task is already holding lock: (&inode->i_alloc_sem){--..}, at: [<ffffffff8022ecd6>] 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){--..}: [<ffffffff802a931d>] lock_acquire+0x4a/0x69 [<ffffffff802a5ed8>] down_write+0x3a/0x47 [<ffffffff8022ecd5>] notify_change+0x104/0x2f7 [<ffffffff802dfc5b>] do_truncate+0x52/0x72 [<ffffffff80212bce>] may_open+0x1d5/0x231 [<ffffffff8021be30>] open_namei+0x2c7/0x6e8 [<ffffffff80229012>] do_filp_open+0x27/0x46 [<ffffffff8021a832>] do_sys_open+0x4e/0xcd [<ffffffff80233c37>] sys_open+0x1a/0x1d [<ffffffff8026060d>] system_call+0x7d/0x83 -> #2 (&sysfs_inode_imutex_key){--..}: [<ffffffff802a931d>] lock_acquire+0x4a/0x69 [<ffffffff80266308>] __mutex_lock_slowpath+0xe4/0x261 [<ffffffff802664ae>] mutex_lock+0x29/0x2e [<ffffffff8030d0f0>] create_dir+0x2c/0x1e2 [<ffffffff8030d6ab>] sysfs_create_dir+0x59/0x78 [<ffffffff80351a76>] kobject_add+0xe5/0x1a9 [<ffffffff803bff5e>] class_device_add+0xb5/0x471 [<ffffffff80430e9d>] netdev_register_sysfs+0x98/0xa2 [<ffffffff80427d25>] register_netdevice+0x289/0x373 [<ffffffff80427e69>] register_netdev+0x5a/0x69 [<ffffffff809937e7>] loopback_init+0x4e/0x53 [<ffffffff809936ed>] net_olddevs_init+0xb/0xb7 [<ffffffff8026d97c>] init+0x1fc/0x3cd [<ffffffff8026155f>] child_rip+0x9/0x12 -> #1 (rtnl_mutex){--..}: [<ffffffff802a931d>] lock_acquire+0x4a/0x69 [<ffffffff80266308>] __mutex_lock_slowpath+0xe4/0x261 [<ffffffff802664ae>] mutex_lock+0x29/0x2e [<ffffffff8042eec1>] rtnl_lock+0xf/0x12 [<ffffffff8045d2eb>] ip_mc_leave_group+0x27/0xc3 [<ffffffff8044708c>] do_ip_setsockopt+0x6ad/0x9b2 [<ffffffff8044743f>] ip_setsockopt+0x2a/0x84 [<ffffffff804554a2>] udp_setsockopt+0xd/0x1c [<ffffffff80420658>] sock_common_setsockopt+0xe/0x11 [<ffffffff8041f795>] sys_setsockopt+0x8e/0xb4 [<ffffffff8026060d>] system_call+0x7d/0x83 -> #0 (sk_lock-AF_INET){--..}: [<ffffffff802a931d>] lock_acquire+0x4a/0x69 [<ffffffff80236121>] lock_sock+0xd4/0xe7 [<ffffffff802276ff>] tcp_sendmsg+0x1e/0xb1d [<ffffffff802473ce>] inet_sendmsg+0x45/0x53 [<ffffffff80257ad6>] sock_sendmsg+0x110/0x130 [<ffffffff804202d0>] kernel_sendmsg+0x3c/0x52 [<ffffffff884ac86b>] xs_tcp_send_request+0x117/0x321 [sunrpc] [<ffffffff884ab896>] xprt_transmit+0xc8/0x1b2 [sunrpc] [<ffffffff884a9463>] call_transmit+0x1f7/0x22e [sunrpc] [<ffffffff884aeccc>] __rpc_execute+0x9b/0x1e6 [sunrpc] [<ffffffff884aee3c>] rpc_execute+0x1a/0x1d [sunrpc] [<ffffffff884a9600>] rpc_call_sync+0x87/0xb9 [sunrpc] [<ffffffff886091ef>] nfs3_rpc_wrapper+0x2e/0x74 [nfs] [<ffffffff886094e5>] nfs3_proc_setattr+0x9c/0xd4 [nfs] [<ffffffff88600994>] nfs_setattr+0xec/0x121 [nfs] [<ffffffff8022ed25>] notify_change+0x154/0x2f7 [<ffffffff802dfc5b>] do_truncate+0x52/0x72 [<ffffffff80212bce>] may_open+0x1d5/0x231 [<ffffffff8021be30>] open_namei+0x2c7/0x6e8 [<ffffffff80229012>] do_filp_open+0x27/0x46 [<ffffffff8021a832>] do_sys_open+0x4e/0xcd [<ffffffff80233c37>] sys_open+0x1a/0x1d [<ffffffff8026060d>] system_call+0x7d/0x83 other info that might help us debug this: 2 locks held by less/9806: #0: (&inode->i_mutex){--..}, at: [<ffffffff802664af>] mutex_lock+0x2a/0x2e #1: (&inode->i_alloc_sem){--..}, at: [<ffffffff8022ecd6>] notify_change+0x105/0x2f7 stack backtrace: Call Trace: [<ffffffff8026e97d>] show_trace+0xae/0x336 [<ffffffff8026ec1a>] dump_stack+0x15/0x17 [<ffffffff802a755b>] print_circular_bug_tail+0x6c/0x77 [<ffffffff802a8b64>] __lock_acquire+0x84d/0xa64 [<ffffffff802a931e>] lock_acquire+0x4b/0x69 [<ffffffff80236122>] lock_sock+0xd5/0xe7 [<ffffffff80227700>] tcp_sendmsg+0x1f/0xb1d [<ffffffff802473cf>] inet_sendmsg+0x46/0x53 [<ffffffff80257ad7>] sock_sendmsg+0x111/0x130 [<ffffffff804202d1>] kernel_sendmsg+0x3d/0x52 [<ffffffff884ac86c>] :sunrpc:xs_tcp_send_request+0x118/0x321 [<ffffffff884ab897>] :sunrpc:xprt_transmit+0xc9/0x1b2 [<ffffffff884a9464>] :sunrpc:call_transmit+0x1f8/0x22e [<ffffffff884aeccd>] :sunrpc:__rpc_execute+0x9c/0x1e6 [<ffffffff884aee3d>] :sunrpc:rpc_execute+0x1b/0x1d [<ffffffff884a9601>] :sunrpc:rpc_call_sync+0x88/0xb9 [<ffffffff886091f0>] :nfs:nfs3_rpc_wrapper+0x2f/0x74 [<ffffffff886094e6>] :nfs:nfs3_proc_setattr+0x9d/0xd4 [<ffffffff88600995>] :nfs:nfs_setattr+0xed/0x121 [<ffffffff8022ed26>] notify_change+0x155/0x2f7 [<ffffffff802dfc5c>] do_truncate+0x53/0x72 [<ffffffff80212bcf>] may_open+0x1d6/0x231 [<ffffffff8021be31>] open_namei+0x2c8/0x6e8 [<ffffffff80229013>] do_filp_open+0x28/0x46 [<ffffffff8021a833>] do_sys_open+0x4f/0xcd [<ffffffff80233c38>] sys_open+0x1b/0x1d [<ffffffff8026060e>] system_call+0x7e/0x83 DWARF2 unwinder stuck at system_call+0x7e/0x83 Leftover inexact backtrace: Version-Release number of selected component (if applicable): 2.6.17-1.2617.2.1.fc6 How reproducible: wouldn't know how Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
*** Bug 205973 has been marked as a duplicate of this bug. ***
False positive: http://lkml.org/lkml/2006/7/13/84 Now to find a way to annotate this.
*** Bug 206961 has been marked as a duplicate of this bug. ***
*** Bug 202146 has been marked as a duplicate of this bug. ***
*** Bug 206953 has been marked as a duplicate of this bug. ***
*** Bug 208125 has been marked as a duplicate of this bug. ***