Bug 426164 - qinq causes kernel "possible recursive locking detected
qinq causes kernel "possible recursive locking detected
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-12-18 17:46 EST by Benny Amorsen
Modified: 2008-02-17 21:57 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-17 21:57:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
boot log showing the problem (61.99 KB, text/plain)
2007-12-18 17:46 EST, Benny Amorsen
no flags Details
Boot log 2.6.24-17.fc9 (130.86 KB, text/plain)
2008-02-06 04:37 EST, Benny Amorsen
no flags Details

  None (edit)
Description Benny Amorsen 2007-12-18 17:46:05 EST
Description of problem:

kernel version is 2.6.24-0.107.rc5.git3.fc9

From boot log on serial console:
(full log attached)

Added VLAN with VID == 2 to IF -:eth0.1568:-

[ INFO: possible recursive locking detected ]
2.6.24-0.107.rc5.git3.fc9 #1
ifconfig/15011 is trying to acquire lock:
 (&vlan_netdev_xmit_lock_key){-+..}, at: [<c05d9450>] dev_mc_sync+0x1c/0x102

but task is already holding lock:
 (&vlan_netdev_xmit_lock_key){-+..}, at: [<c05d51bd>] dev_set_rx_mode+0x14/0x3c

other info that might help us debug this:
2 locks held by ifconfig/15011:
 #0:  (rtnl_mutex){--..}, at: [<c05de4f7>] rtnl_lock+0xf/0x11
 #1:  (&vlan_netdev_xmit_lock_key){-+..}, at: [<c05d51bd>] dev_set_rx_mode+0x14/0x3c

stack backtrace:
Pid: 15011, comm: ifconfig Not tainted 2.6.24-0.107.rc5.git3.fc9 #1
 [<c040649a>] show_trace_log_lvl+0x1a/0x2f
 [<c0406d41>] show_trace+0x12/0x14
 [<c0407061>] dump_stack+0x6c/0x72
 [<c044cfb3>] __lock_acquire+0x815/0xb5f
 [<c044d6f5>] lock_acquire+0x7b/0x9e
 [<c063dcf5>] _spin_lock_bh+0x33/0x5d
 [<c05d9450>] dev_mc_sync+0x1c/0x102
 [<f8b24c96>] vlan_dev_set_multicast_list+0x15/0x17 [8021q]
 [<c05d5107>] __dev_set_rx_mode+0x7e/0x81
 [<c05d51d0>] dev_set_rx_mode+0x27/0x3c
 [<c05d749e>] dev_open+0x61/0x7b
 [<c05d60b0>] dev_change_flags+0xa4/0x152
 [<c0616b8d>] devinet_ioctl+0x211/0x518
 [<c061723b>] inet_ioctl+0x86/0xa4
 [<c05caf0b>] sock_ioctl+0x1ca/0x1eb
 [<c049cdf2>] do_ioctl+0x22/0x67
 [<c049d080>] vfs_ioctl+0x249/0x25c
 [<c049d0d5>] sys_ioctl+0x42/0x5d
 [<c0405252>] syscall_call+0x7/0xb
Comment 1 Benny Amorsen 2007-12-18 17:46:05 EST
Created attachment 289953 [details]
boot log showing the problem
Comment 2 Benny Amorsen 2008-02-06 04:37:42 EST
Created attachment 294083 [details]
Boot log 2.6.24-17.fc9
Comment 3 Benny Amorsen 2008-02-06 04:39:14 EST
The problem manifests itself a bit differently in 2.6.24-17.fc9. The above
attachment has the scoop.
Comment 4 Benny Amorsen 2008-02-15 07:40:30 EST
Fixed in kernel-2.6.25-0.40.rc1.git2.fc9

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