lkml.org 
[lkml]   [2007]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject2.6.21.4: possible circular locking dependency detected
Hello,

While copying a small file over to a windows box via cifs, once again I
got something like this:

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.21.4 #8
-------------------------------------------------------
cp/3088 is trying to acquire lock:
(sk_lock-AF_INET){--..}, at: [<c02c5c99>] tcp_sendmsg+0x16/0x9cc

but task is already holding lock:
(&inode->i_alloc_sem){--..}, at: [<c0167e08>] notify_change+0xe8/0x2d0

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #3 (&inode->i_alloc_sem){--..}:
[<c012c0c8>] __lock_acquire+0x9e1/0xb85
[<c012c2d4>] lock_acquire+0x68/0x82
[<c0126503>] down_write+0x3a/0x53
[<c0167e08>] notify_change+0xe8/0x2d0
[<c0154dee>] do_truncate+0x53/0x6c
[<c015d77c>] may_open+0x1ba/0x202
[<c015f6e6>] open_namei+0x27f/0x5af
[<c0154b53>] do_filp_open+0x26/0x3b
[<c0154bab>] do_sys_open+0x43/0xc2
[<c0154c62>] sys_open+0x1c/0x1e
[<c01026a6>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff

-> #2 (&sysfs_inode_imutex_key){--..}:
[<c012c0c8>] __lock_acquire+0x9e1/0xb85
[<c012c2d4>] lock_acquire+0x68/0x82
[<c02f7c0a>] __mutex_lock_slowpath+0xdc/0x266
[<c02f7db0>] mutex_lock+0x1c/0x1f
[<c018c41d>] create_dir+0x20/0x196
[<c018c5dd>] sysfs_create_dir+0x4a/0x64
[<c01d2bd9>] kobject_shadow_add+0xd6/0x189
[<c01d2c96>] kobject_add+0xa/0xc
[<c0223ee5>] device_add+0xae/0x62b
[<c02aaed3>] netdev_register_sysfs+0x5a/0x5f
[<c02a102a>] register_netdevice+0x22c/0x2e4
[<c02a2175>] register_netdev+0x40/0x4d
[<c022c124>] rhine_init_one+0x492/0x64f
[<c01e1ffd>] pci_device_probe+0x39/0x5b
[<c0225e0b>] really_probe+0xbd/0x145
[<c0225f28>] driver_probe_device+0x95/0xa1
[<c022603d>] __driver_attach+0x6a/0xa1
[<c0225401>] bus_for_each_dev+0x36/0x5b
[<c0225c7f>] driver_attach+0x19/0x1b
[<c02256e8>] bus_add_driver+0x6a/0x170
[<c022624f>] driver_register+0x79/0x7e
[<c01e2184>] __pci_register_driver+0x7b/0xa8
[<c040a0de>] rhine_init+0x5d/0x5f
[<c03f271c>] init+0x95/0x17a
[<c01038e7>] kernel_thread_helper+0x7/0x10
[<ffffffff>] 0xffffffff

-> #1 (rtnl_mutex){--..}:
[<c012c0c8>] __lock_acquire+0x9e1/0xb85
[<c012c2d4>] lock_acquire+0x68/0x82
[<c02f7c0a>] __mutex_lock_slowpath+0xdc/0x266
[<c02f7db0>] mutex_lock+0x1c/0x1f
[<c02a8913>] rtnl_lock+0xd/0xf
[<c02e0e9d>] ip_mc_join_group+0x2c/0xc9
[<c02c2573>] ip_setsockopt+0x64b/0x9a7
[<c02d7d10>] udp_setsockopt+0x43/0x4a
[<c029a01e>] sock_common_setsockopt+0x1e/0x24
[<c02986e7>] sys_setsockopt+0x7b/0x97
[<c0299d39>] sys_socketcall+0x1e8/0x241
[<c01026a6>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff

-> #0 (sk_lock-AF_INET){--..}:
[<c012bfa9>] __lock_acquire+0x8c2/0xb85
[<c012c2d4>] lock_acquire+0x68/0x82
[<c029a747>] lock_sock_nested+0xba/0xc7
[<c02c5c99>] tcp_sendmsg+0x16/0x9cc
[<c02dd764>] inet_sendmsg+0x3e/0x49
[<c0298b77>] sock_sendmsg+0xe7/0x104
[<c0299dba>] kernel_sendmsg+0x28/0x37
[<ded22eba>] smb_send+0x92/0x11c [cifs]
[<ded230c3>] SendReceive+0x17f/0x3dc [cifs]
[<ded12817>] CIFSSMBSetEOF+0x1e6/0x229 [cifs]
[<ded1e4dd>] cifs_setattr+0x25d/0x900 [cifs]
[<c0167e50>] notify_change+0x130/0x2d0
[<c0154dee>] do_truncate+0x53/0x6c
[<c015d77c>] may_open+0x1ba/0x202
[<c015f6e6>] open_namei+0x27f/0x5af
[<c0154b53>] do_filp_open+0x26/0x3b
[<c0154bab>] do_sys_open+0x43/0xc2
[<c0154c62>] sys_open+0x1c/0x1e
[<c01026a6>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff

other info that might help us debug this:

2 locks held by cp/3088:
#0: (&inode->i_mutex){--..}, at: [<c02f7db0>] mutex_lock+0x1c/0x1f
#1: (&inode->i_alloc_sem){--..}, at: [<c0167e08>] notify_change+0xe8/0x2d0

stack backtrace:
[<c0103c43>] show_trace_log_lvl+0x1a/0x2f
[<c01042bc>] show_trace+0x12/0x14
[<c0104359>] dump_stack+0x16/0x18
[<c012a7e1>] print_circular_bug_tail+0x5f/0x68
[<c012bfa9>] __lock_acquire+0x8c2/0xb85
[<c012c2d4>] lock_acquire+0x68/0x82
[<c029a747>] lock_sock_nested+0xba/0xc7
[<c02c5c99>] tcp_sendmsg+0x16/0x9cc
[<c02dd764>] inet_sendmsg+0x3e/0x49
[<c0298b77>] sock_sendmsg+0xe7/0x104
[<c0299dba>] kernel_sendmsg+0x28/0x37
[<ded22eba>] smb_send+0x92/0x11c [cifs]
[<ded230c3>] SendReceive+0x17f/0x3dc [cifs]
[<ded12817>] CIFSSMBSetEOF+0x1e6/0x229 [cifs]
[<ded1e4dd>] cifs_setattr+0x25d/0x900 [cifs]
[<c0167e50>] notify_change+0x130/0x2d0
[<c0154dee>] do_truncate+0x53/0x6c
[<c015d77c>] may_open+0x1ba/0x202
[<c015f6e6>] open_namei+0x27f/0x5af
[<c0154b53>] do_filp_open+0x26/0x3b
[<c0154bab>] do_sys_open+0x43/0xc2
[<c0154c62>] sys_open+0x1c/0x1e
[<c01026a6>] sysenter_past_esp+0x5f/0x99
=======================
pwc: Too many ISOC errors, bailing out.
pwc: Too many ISOC errors, bailing out.
pwc: Too many ISOC errors, bailing out.
pwc: Too many ISOC errors, bailing out.
pwc: Too many ISOC errors, bailing out.
pwc: Too many ISOC errors, bailing out.
Clocksource tsc unstable (delta = 18746609409 ns)
Time: acpi_pm clocksource has been installed.
pwc: Too many ISOC errors, bailing out.
pwc: Too many ISOC errors, bailing out.
pwc: Too many ISOC errors, bailing out.
pwc: Too many ISOC errors, bailing out.
pwc: Too many ISOC errors, bailing out.
pwc: Too many ISOC errors, bailing out.
CIFS VFS: No response for cmd 50 mid 5023


How can this be fixed?
Afterwards nut (ups tool) is slightly upset.

Kind regards,
Udo
-
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/

\
 
 \ /
  Last update: 2007-06-21 19:57    [W:0.054 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site