From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Jones Subject: starting mc triggers lockdep Date: Fri, 7 Jul 2006 12:13:14 -0400 Message-ID: <20060707161314.GA3223@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netdev@vger.kernel.org Return-path: Received: from mx1.redhat.com ([66.187.233.31]:45270 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S932147AbWGGQNU (ORCPT ); Fri, 7 Jul 2006 12:13:20 -0400 To: Linux Kernel Content-Disposition: inline Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org With 2.6.18rc1 + a selection of the lockdep tweaks found so far, midnight commander makes the kernel unhappy. Dave ======================================================= [ INFO: possible circular locking dependency detected ] ------------------------------------------------------- mc/4913 is trying to acquire lock: (sk_lock-AF_INET){--..}, at: [] tcp_sendmsg+0x1f/0xb1a but task is already holding lock: (&inode->i_mutex){--..}, at: [] mutex_lock+0x2a/0x2e which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&inode->i_mutex){--..}: [] lock_acquire+0x4a/0x69 [] __mutex_lock_slowpath+0xeb/0x29f [] mutex_lock+0x29/0x2e [] create_dir+0x2c/0x1e2 [] sysfs_create_dir+0x59/0x78 [] kobject_add+0x114/0x1d8 [] class_device_add+0xb5/0x49d [] netdev_register_sysfs+0x98/0xa2 [] register_netdevice+0x28c/0x376 [] register_netdev+0x5a/0x69 [] loopback_init+0x4e/0x53 [] net_olddevs_init+0xb/0xb7 [] init+0x177/0x348 [] child_rip+0x7/0x12 -> #1 (rtnl_mutex){--..}: [] lock_acquire+0x4a/0x69 [] __mutex_lock_slowpath+0xeb/0x29f [] mutex_lock+0x29/0x2e [] rtnl_lock+0xf/0x12 [] ip_mc_leave_group+0x1e/0xae [] do_ip_setsockopt+0x6ad/0x9b2 [] ip_setsockopt+0x2a/0x84 [] udp_setsockopt+0xd/0x1c [] sock_common_setsockopt+0xe/0x11 [] sys_setsockopt+0x8e/0xb4 [] tracesys+0xd0/0xdb -> #0 (sk_lock-AF_INET){--..}: [] lock_acquire+0x4a/0x69 [] lock_sock+0xd4/0xe7 [] tcp_sendmsg+0x1e/0xb1a [] inet_sendmsg+0x45/0x53 [] sock_sendmsg+0x110/0x130 [] kernel_sendmsg+0x3c/0x52 [] xs_tcp_send_request+0x117/0x320 [sunrpc] [] xprt_transmit+0x105/0x21e [sunrpc] [] call_transmit+0x1f4/0x239 [sunrpc] [] __rpc_execute+0x9b/0x1e6 [sunrpc] [] rpc_execute+0x1a/0x1d [sunrpc] [] rpc_call_sync+0x87/0xb9 [sunrpc] [] nfs3_rpc_wrapper+0x2e/0x74 [nfs] [] nfs3_proc_lookup+0xe0/0x163 [nfs] [] nfs_lookup+0xef/0x1d6 [nfs] [] do_lookup+0xd0/0x18c [] __link_path_walk+0xa29/0xf7d [] link_path_walk+0x69/0x101 [] __link_path_walk+0xd2d/0xf7d [] link_path_walk+0x69/0x101 [] do_path_lookup+0x27b/0x2e7 [] __user_walk_fd+0x40/0x5c [] vfs_stat_fd+0x26/0x5d [] sys_newstat+0x21/0x3c [] tracesys+0xd0/0xdb other info that might help us debug this: 1 lock held by mc/4913: #0: (&inode->i_mutex){--..}, at: [] mutex_lock+0x2a/0x2e stack backtrace: Call Trace: [] show_trace+0xaa/0x23d [] dump_stack+0x15/0x17 [] print_circular_bug_tail+0x6c/0x77 [] __lock_acquire+0x853/0xa54 [] lock_acquire+0x4b/0x69 [] lock_sock+0xd5/0xe7 [] tcp_sendmsg+0x1f/0xb1a [] inet_sendmsg+0x46/0x53 [] sock_sendmsg+0x111/0x130 [] kernel_sendmsg+0x3d/0x52 [] :sunrpc:xs_tcp_send_request+0x118/0x320 [] :sunrpc:xprt_transmit+0x106/0x21e [] :sunrpc:call_transmit+0x1f5/0x239 [] :sunrpc:__rpc_execute+0x9c/0x1e6 [] :sunrpc:rpc_execute+0x1b/0x1d [] :sunrpc:rpc_call_sync+0x88/0xb9 [] :nfs:nfs3_rpc_wrapper+0x2f/0x74 [] :nfs:nfs3_proc_lookup+0xe1/0x163 [] :nfs:nfs_lookup+0xf0/0x1d6 [] do_lookup+0xd1/0x18c [] __link_path_walk+0xa2a/0xf7d [] link_path_walk+0x6a/0x101 [] __link_path_walk+0xd2e/0xf7d [] link_path_walk+0x6a/0x101 [] do_path_lookup+0x27c/0x2e7 [] __user_walk_fd+0x41/0x5c [] vfs_stat_fd+0x27/0x5d [] sys_newstat+0x22/0x3c [] tracesys+0xd1/0xdb -- http://www.codemonkey.org.uk