Bug 198060 - kernel gets a circular lock from automount and NFS
kernel gets a circular lock from automount and NFS
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-08 18:06 EDT by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-12 00:04:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2006-07-08 18:06:43 EDT
Description of problem:

I got the following when using automount with a remote file system
exported via NFS.  An operation succeeded after that.

=======================================================
[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
automount/4496 is trying to acquire lock:
 (sk_lock-AF_INET){--..}, at: [<ffffffff8022800c>] tcp_sendmsg+0x1f/0xb1a

but task is already holding lock:
 (&inode->i_mutex){--..}, at: [<ffffffff802692e0>] mutex_lock+0x2a/0x2e

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (&inode->i_mutex){--..}:
       [<ffffffff802ab6bd>] lock_acquire+0x4a/0x69
       [<ffffffff80269102>] __mutex_lock_slowpath+0xeb/0x29f
       [<ffffffff802692df>] mutex_lock+0x29/0x2e
       [<ffffffff8030ec86>] create_dir+0x2c/0x1e2
       [<ffffffff8030f241>] sysfs_create_dir+0x59/0x78
       [<ffffffff8034cac8>] kobject_add+0x114/0x1d8
       [<ffffffff803ba9cd>] class_device_add+0xb5/0x49d
       [<ffffffff8042f897>] netdev_register_sysfs+0x98/0xa2
       [<ffffffff8042673e>] register_netdevice+0x28c/0x376
       [<ffffffff80426882>] register_netdev+0x5a/0x69
       [<ffffffff8098aa12>] loopback_init+0x4e/0x53
       [<ffffffff8098a918>] net_olddevs_init+0xb/0xb7
       [<ffffffff80270900>] init+0x177/0x348
       [<ffffffff80263cdd>] child_rip+0x7/0x12

-> #1 (rtnl_mutex){--..}:
       [<ffffffff802ab6bd>] lock_acquire+0x4a/0x69
       [<ffffffff80269102>] __mutex_lock_slowpath+0xeb/0x29f
       [<ffffffff802692df>] mutex_lock+0x29/0x2e
       [<ffffffff8042d888>] rtnl_lock+0xf/0x12
       [<ffffffff8045bf9e>] ip_mc_leave_group+0x1e/0xae
       [<ffffffff80445fdd>] do_ip_setsockopt+0x6ad/0x9b2
       [<ffffffff80446390>] ip_setsockopt+0x2a/0x84
       [<ffffffff8045423b>] udp_setsockopt+0xd/0x1c
       [<ffffffff8041efd0>] sock_common_setsockopt+0xe/0x11
       [<ffffffff8041e14b>] sys_setsockopt+0x8e/0xb4
       [<ffffffff80262f19>] tracesys+0xd0/0xdb

-> #0 (sk_lock-AF_INET){--..}:
       [<ffffffff802ab6bd>] lock_acquire+0x4a/0x69
       [<ffffffff802371ea>] lock_sock+0xd4/0xe7
       [<ffffffff8022800b>] tcp_sendmsg+0x1e/0xb1a
       [<ffffffff80248f4b>] inet_sendmsg+0x45/0x53
       [<ffffffff80259d25>] sock_sendmsg+0x110/0x130
       [<ffffffff8041ec48>] kernel_sendmsg+0x3c/0x52
       [<ffffffff884e19e9>] xs_tcp_send_request+0x117/0x320 [sunrpc]
       [<ffffffff884e08d5>] xprt_transmit+0x105/0x21e [sunrpc]
       [<ffffffff884df71e>] call_transmit+0x1f4/0x239 [sunrpc]
       [<ffffffff884e406e>] __rpc_execute+0x9b/0x1e6 [sunrpc]
       [<ffffffff884e41de>] rpc_execute+0x1a/0x1d [sunrpc]
       [<ffffffff884de4ad>] rpc_call_sync+0x87/0xb9 [sunrpc]
       [<ffffffff885df587>] nfs3_rpc_wrapper+0x2e/0x74 [nfs]
       [<ffffffff885dfa14>] nfs3_proc_lookup+0xe0/0x163 [nfs]
       [<ffffffff885d1b10>] nfs_lookup+0xef/0x1d6 [nfs]
       [<ffffffff8020d300>] do_lookup+0xd0/0x18c
       [<ffffffff80209f27>] __link_path_walk+0xa29/0xf7d
       [<ffffffff8020f076>] link_path_walk+0x69/0x101
       [<ffffffff8020d096>] do_path_lookup+0x27b/0x2e7
       [<ffffffff802258da>] __user_walk_fd+0x40/0x5c
       [<ffffffff8022ae4a>] vfs_stat_fd+0x26/0x5d
       [<ffffffff80225592>] sys_newstat+0x21/0x3c
       [<ffffffff80262f19>] tracesys+0xd0/0xdb

other info that might help us debug this:

1 lock held by automount/4496:
 #0:  (&inode->i_mutex){--..}, at: [<ffffffff802692e0>] mutex_lock+0x2a/0x2e

stack backtrace:

Call Trace:
 [<ffffffff802718f8>] show_trace+0xaa/0x23d
 [<ffffffff80271aa0>] dump_stack+0x15/0x17
 [<ffffffff802a9917>] print_circular_bug_tail+0x6c/0x77
 [<ffffffff802aaf1c>] __lock_acquire+0x853/0xa54
 [<ffffffff802ab6be>] lock_acquire+0x4b/0x69
 [<ffffffff802371eb>] lock_sock+0xd5/0xe7
 [<ffffffff8022800c>] tcp_sendmsg+0x1f/0xb1a
 [<ffffffff80248f4c>] inet_sendmsg+0x46/0x53
 [<ffffffff80259d26>] sock_sendmsg+0x111/0x130
 [<ffffffff8041ec49>] kernel_sendmsg+0x3d/0x52
 [<ffffffff884e19ea>] :sunrpc:xs_tcp_send_request+0x118/0x320
 [<ffffffff884e08d6>] :sunrpc:xprt_transmit+0x106/0x21e
 [<ffffffff884df71f>] :sunrpc:call_transmit+0x1f5/0x239
 [<ffffffff884e406f>] :sunrpc:__rpc_execute+0x9c/0x1e6
 [<ffffffff884e41df>] :sunrpc:rpc_execute+0x1b/0x1d
 [<ffffffff884de4ae>] :sunrpc:rpc_call_sync+0x88/0xb9
 [<ffffffff885df588>] :nfs:nfs3_rpc_wrapper+0x2f/0x74
 [<ffffffff885dfa15>] :nfs:nfs3_proc_lookup+0xe1/0x163
 [<ffffffff885d1b11>] :nfs:nfs_lookup+0xf0/0x1d6
 [<ffffffff8020d301>] do_lookup+0xd1/0x18c
 [<ffffffff80209f28>] __link_path_walk+0xa2a/0xf7d
 [<ffffffff8020f077>] link_path_walk+0x6a/0x101
 [<ffffffff8020d097>] do_path_lookup+0x27c/0x2e7
 [<ffffffff802258db>] __user_walk_fd+0x41/0x5c
 [<ffffffff8022ae4b>] vfs_stat_fd+0x27/0x5d
 [<ffffffff80225593>] sys_newstat+0x22/0x3c
 [<ffffffff80262f1a>] tracesys+0xd1/0xdb


Version-Release number of selected component (if applicable):
kernel-2.6.17-1.2358.fc6

How reproducible:
non-obvious; looks like a timing sensitive
Comment 1 Dave Jones 2006-07-12 00:04:31 EDT
should be fixed in tomorrows rawhide push (kernel-2.6.17-1.2375.fc6 or higher).

Note You need to log in before you can comment on or make changes to this bug.