* Lockdep warning
@ 2011-08-26 17:29 Larry Finger
2011-08-26 20:18 ` Shaun Ruffell
0 siblings, 1 reply; 13+ messages in thread
From: Larry Finger @ 2011-08-26 17:29 UTC (permalink / raw)
To: LKML
With a new version of the staging driver rtl8192e, I'm getting the lockdep
warning posted below. The lock in question is for a timer that uses init_timer()
for initialization. From the definition of that macro, I thought this was
initialized with a lock_class_key that should prevent this warning. Obviously,
I'm missing something.
Any pointers would be appreciated.
Thanks,
Larry
[ 88.048077] =============================================
[ 88.048086] [ INFO: possible recursive locking detected ]
[ 88.048093] 3.1.0-rc3-staging+ #5
[ 88.048097] ---------------------------------------------
[ 88.048102] kmemleak/631 is trying to acquire lock:
[ 88.048108] (ptimer){+.-...}, at: [<ffffffff81059370>] del_timer_sync+0x0/0xc0
[ 88.048124]
[ 88.048125] but task is already holding lock:
[ 88.048131] (ptimer){+.-...}, at: [<ffffffff81058e54>]
run_timer_softirq+0x124/0x400
[ 88.048142]
[ 88.048143] other info that might help us debug this:
[ 88.048149] Possible unsafe locking scenario:
[ 88.048150]
[ 88.048156] CPU0
[ 88.048159] ----
[ 88.048162] lock(ptimer);
[ 88.048167] lock(ptimer);
[ 88.048172]
[ 88.048173] *** DEADLOCK ***
[ 88.048174]
[ 88.048179] May be due to missing lock nesting notation
[ 88.048180]
[ 88.048187] 2 locks held by kmemleak/631:
[ 88.048191] #0: (scan_mutex){+.+...}, at: [<ffffffff81122e76>]
kmemleak_scan_thread+0x56/0xd0
[ 88.048206] #1: (ptimer){+.-...}, at: [<ffffffff81058e54>]
run_timer_softirq+0x124/0x400
[ 88.048218]
[ 88.048219] stack backtrace:
[ 88.048225] Pid: 631, comm: kmemleak Tainted: G C 3.1.0-rc3-staging+ #5
[ 88.048232] Call Trace:
[ 88.048236] <IRQ> [<ffffffff81083cbb>] __lock_acquire+0x119b/0x1ea0
[ 88.048254] [<ffffffff81084fa5>] lock_acquire+0x95/0x120
[ 88.048263] [<ffffffff81059370>] ? process_timeout+0x10/0x10
[ 88.048272] [<ffffffff810593ac>] del_timer_sync+0x3c/0xc0
[ 88.048280] [<ffffffff81059370>] ? process_timeout+0x10/0x10
[ 88.048289] [<ffffffff81058e54>] ? run_timer_softirq+0x124/0x400
[ 88.048316] [<ffffffffa008d1ee>] TsInitAddBA+0x6e/0x170 [r8192e_pci]
[ 88.048332] [<ffffffffa008b4b3>] TsAddBaProcess+0x33/0x50 [r8192e_pci]
[ 88.048341] [<ffffffff81058edb>] run_timer_softirq+0x1ab/0x400
[ 88.048350] [<ffffffff81058e54>] ? run_timer_softirq+0x124/0x400
[ 88.048364] [<ffffffffa008b480>] ? RxPktPendingTimeout+0x2d0/0x2d0 [r8192e_pci]
[ 88.048377] [<ffffffff810502ad>] __do_softirq+0xbd/0x210
[ 88.048386] [<ffffffff810714d7>] ? hrtimer_interrupt+0x137/0x240
[ 88.048396] [<ffffffff8137176c>] call_softirq+0x1c/0x30
[ 88.048406] [<ffffffff810048c5>] do_softirq+0x85/0xc0
[ 88.048414] [<ffffffff81050686>] irq_exit+0x96/0xc0
[ 88.048422] [<ffffffff8101e4e9>] smp_apic_timer_interrupt+0x69/0xa0
[ 88.048431] [<ffffffff8136fff0>] apic_timer_interrupt+0x70/0x80
[ 88.048438] <EOI> [<ffffffff8136ea4d>] ? _raw_spin_unlock_irqrestore+0x3d/0x70
[ 88.048452] [<ffffffff81122315>] scan_gray_list+0x155/0x170
[ 88.048460] [<ffffffff8112262b>] kmemleak_scan+0x2fb/0x6e0
[ 88.048468] [<ffffffff81122330>] ? scan_gray_list+0x170/0x170
[ 88.048477] [<ffffffff81122e20>] ? kmemleak_write+0x390/0x390
[ 88.048485] [<ffffffff81122e20>] ? kmemleak_write+0x390/0x390
[ 88.048494] [<ffffffff81122e7b>] kmemleak_scan_thread+0x5b/0xd0
[ 88.048502] [<ffffffff81122e20>] ? kmemleak_write+0x390/0x390
[ 88.048510] [<ffffffff8106c8e6>] kthread+0x96/0xa0
[ 88.048519] [<ffffffff81371674>] kernel_thread_helper+0x4/0x10
[ 88.048527] [<ffffffff8136ed9d>] ? retint_restore_args+0xe/0xe
[ 88.048536] [<ffffffff8106c850>] ? __init_kthread_worker+0x70/0x70
[ 88.048544] [<ffffffff81371670>] ? gs_change+0xb/0xb
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Lockdep warning
2011-08-26 17:29 Lockdep warning Larry Finger
@ 2011-08-26 20:18 ` Shaun Ruffell
0 siblings, 0 replies; 13+ messages in thread
From: Shaun Ruffell @ 2011-08-26 20:18 UTC (permalink / raw)
To: Larry Finger; +Cc: LKML
On Fri, Aug 26, 2011 at 12:29:01PM -0500, Larry Finger wrote:
> With a new version of the staging driver rtl8192e, I'm getting the
> lockdep warning posted below. The lock in question is for a timer
> that uses init_timer() for initialization. From the definition of
> that macro, I thought this was initialized with a lock_class_key
> that should prevent this warning. Obviously, I'm missing something.
>
> Any pointers would be appreciated.
>
> Thanks,
>
> Larry
>
>
> [ 88.048077] =============================================
> [ 88.048086] [ INFO: possible recursive locking detected ]
> [ 88.048093] 3.1.0-rc3-staging+ #5
> [ 88.048097] ---------------------------------------------
> [ 88.048102] kmemleak/631 is trying to acquire lock:
> [ 88.048108] (ptimer){+.-...}, at: [<ffffffff81059370>] del_timer_sync+0x0/0xc0
> [ 88.048124]
> [ 88.048125] but task is already holding lock:
> [ 88.048131] (ptimer){+.-...}, at: [<ffffffff81058e54>]
> run_timer_softirq+0x124/0x400
> [ 88.048142]
> [ 88.048143] other info that might help us debug this:
> [ 88.048149] Possible unsafe locking scenario:
> [ 88.048150]
> [ 88.048156] CPU0
> [ 88.048159] ----
> [ 88.048162] lock(ptimer);
> [ 88.048167] lock(ptimer);
> [ 88.048172]
> [ 88.048173] *** DEADLOCK ***
> [ 88.048174]
> [ 88.048179] May be due to missing lock nesting notation
> [ 88.048180]
> [ 88.048187] 2 locks held by kmemleak/631:
> [ 88.048191] #0: (scan_mutex){+.+...}, at: [<ffffffff81122e76>]
> kmemleak_scan_thread+0x56/0xd0
> [ 88.048206] #1: (ptimer){+.-...}, at: [<ffffffff81058e54>]
> run_timer_softirq+0x124/0x400
> [ 88.048218]
> [ 88.048219] stack backtrace:
> [ 88.048225] Pid: 631, comm: kmemleak Tainted: G C 3.1.0-rc3-staging+ #5
> [ 88.048232] Call Trace:
> [ 88.048236] <IRQ> [<ffffffff81083cbb>] __lock_acquire+0x119b/0x1ea0
> [ 88.048254] [<ffffffff81084fa5>] lock_acquire+0x95/0x120
> [ 88.048263] [<ffffffff81059370>] ? process_timeout+0x10/0x10
> [ 88.048272] [<ffffffff810593ac>] del_timer_sync+0x3c/0xc0
> [ 88.048280] [<ffffffff81059370>] ? process_timeout+0x10/0x10
> [ 88.048289] [<ffffffff81058e54>] ? run_timer_softirq+0x124/0x400
> [ 88.048316] [<ffffffffa008d1ee>] TsInitAddBA+0x6e/0x170 [r8192e_pci]
> [ 88.048332] [<ffffffffa008b4b3>] TsAddBaProcess+0x33/0x50 [r8192e_pci]
> [ 88.048341] [<ffffffff81058edb>] run_timer_softirq+0x1ab/0x400
> [ 88.048350] [<ffffffff81058e54>] ? run_timer_softirq+0x124/0x400
> [ 88.048364] [<ffffffffa008b480>] ? RxPktPendingTimeout+0x2d0/0x2d0 [r8192e_pci]
> [ 88.048377] [<ffffffff810502ad>] __do_softirq+0xbd/0x210
> [ 88.048386] [<ffffffff810714d7>] ? hrtimer_interrupt+0x137/0x240
> [ 88.048396] [<ffffffff8137176c>] call_softirq+0x1c/0x30
> [ 88.048406] [<ffffffff810048c5>] do_softirq+0x85/0xc0
> [ 88.048414] [<ffffffff81050686>] irq_exit+0x96/0xc0
> [ 88.048422] [<ffffffff8101e4e9>] smp_apic_timer_interrupt+0x69/0xa0
> [ 88.048431] [<ffffffff8136fff0>] apic_timer_interrupt+0x70/0x80
> [ 88.048438] <EOI> [<ffffffff8136ea4d>] ? _raw_spin_unlock_irqrestore+0x3d/0x70
> [ 88.048452] [<ffffffff81122315>] scan_gray_list+0x155/0x170
> [ 88.048460] [<ffffffff8112262b>] kmemleak_scan+0x2fb/0x6e0
> [ 88.048468] [<ffffffff81122330>] ? scan_gray_list+0x170/0x170
> [ 88.048477] [<ffffffff81122e20>] ? kmemleak_write+0x390/0x390
> [ 88.048485] [<ffffffff81122e20>] ? kmemleak_write+0x390/0x390
> [ 88.048494] [<ffffffff81122e7b>] kmemleak_scan_thread+0x5b/0xd0
> [ 88.048502] [<ffffffff81122e20>] ? kmemleak_write+0x390/0x390
> [ 88.048510] [<ffffffff8106c8e6>] kthread+0x96/0xa0
> [ 88.048519] [<ffffffff81371674>] kernel_thread_helper+0x4/0x10
> [ 88.048527] [<ffffffff8136ed9d>] ? retint_restore_args+0xe/0xe
> [ 88.048536] [<ffffffff8106c850>] ? __init_kthread_worker+0x70/0x70
> [ 88.048544] [<ffffffff81371670>] ? gs_change+0xb/0xb
It does not look like it's currently safe to call del_timer_sync in
softirq context [1].
[1] http://thread.gmane.org/gmane.linux.kernel/1097241/focus=1097476
--
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Lockdep warning
2013-12-19 14:04 ` Jonas Bonn
@ 2013-12-19 14:14 ` Borislav Petkov
0 siblings, 0 replies; 13+ messages in thread
From: Borislav Petkov @ 2013-12-19 14:14 UTC (permalink / raw)
To: Jonas Bonn; +Cc: linux-kernel, netdev
On Thu, Dec 19, 2013 at 03:04:37PM +0100, Jonas Bonn wrote:
> Ah... my bad. Thanks!
>
> Sorry for the noise.
No worries, keep testing -rcs and reporting issues - it is appreciated!
:-)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Lockdep warning
2013-12-19 14:02 ` Borislav Petkov
@ 2013-12-19 14:04 ` Jonas Bonn
2013-12-19 14:14 ` Borislav Petkov
0 siblings, 1 reply; 13+ messages in thread
From: Jonas Bonn @ 2013-12-19 14:04 UTC (permalink / raw)
To: Borislav Petkov; +Cc: linux-kernel, netdev
On 12/19/2013 03:02 PM, Borislav Petkov wrote:
> On Thu, Dec 19, 2013 at 02:36:40PM +0100, Jonas Bonn wrote:
>
> In such situations I'd always search the net first, to see whether this
> has been fixed already. Hint: try searching for "lockdep __udp4_lib_rcv"
Ah... my bad. Thanks!
Sorry for the noise.
/Jonas
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Lockdep warning
2013-12-19 13:36 Jonas Bonn
@ 2013-12-19 14:02 ` Borislav Petkov
2013-12-19 14:04 ` Jonas Bonn
0 siblings, 1 reply; 13+ messages in thread
From: Borislav Petkov @ 2013-12-19 14:02 UTC (permalink / raw)
To: Jonas Bonn; +Cc: linux-kernel, netdev
On Thu, Dec 19, 2013 at 02:36:40PM +0100, Jonas Bonn wrote:
> Hi,
>
> Here's a lockdep warning that I'm seeing on an MX28 with 3.13-rc4.
> This seems to happen as soon as the network link comes up...
> including the 'netdev' list here as the backtrace shows the FEC
> driver in the stacktrace.
>
> Any advice on how to proceed to track this down appreciated...
In such situations I'd always search the net first, to see whether this
has been fixed already. Hint: try searching for "lockdep __udp4_lib_rcv"
:-)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 13+ messages in thread
* Lockdep warning
@ 2013-12-19 13:36 Jonas Bonn
2013-12-19 14:02 ` Borislav Petkov
0 siblings, 1 reply; 13+ messages in thread
From: Jonas Bonn @ 2013-12-19 13:36 UTC (permalink / raw)
To: linux-kernel, netdev
Hi,
Here's a lockdep warning that I'm seeing on an MX28 with 3.13-rc4. This
seems to happen as soon as the network link comes up... including the
'netdev' list here as the backtrace shows the FEC driver in the stacktrace.
Any advice on how to proceed to track this down appreciated...
/Jonas
[ 37.140857] fec 800f0000.ethernet eth0: Freescale FEC PHY driver
[Generic PHY] (mii_bus:phy_addr=800f0000.etherne:00, irq=-1)
[ 37.148951] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 39.155538] libphy: 800f0000.etherne:00 - Link is Up - 100/Full
[ 39.162273] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 41.167998]
[ 41.169546] =================================
[ 41.173925] [ INFO: inconsistent lock state ]
[ 41.178308] 3.13.0-rc4-00018-g3b78c2f-dirty #8 Not tainted
[ 41.183808] ---------------------------------
[ 41.188182] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 41.194213] connmand/337 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 41.199452] (&(&sk->sk_dst_lock)->rlock){+.?...}, at: [<c03d8088>]
__udp4_lib_rcv+0x7e0/0x8a8
[ 41.208175] {SOFTIRQ-ON-W} state was registered at:
[ 41.213071] [<c0046cb8>] __lock_acquire+0x5d0/0x1a64
[ 41.218274] [<c0048694>] lock_acquire+0x9c/0x104
[ 41.223115] [<c046a690>] _raw_spin_lock+0x28/0x38
[ 41.228052] [<c042be50>] ip6_datagram_connect+0x258/0x43c
[ 41.233669] [<c03e0478>] inet_dgram_connect+0x58/0x84
[ 41.238945] [<c0376c7c>] SyS_connect+0x64/0x8c
[ 41.243610] [<c0009560>] ret_fast_syscall+0x0/0x44
[ 41.248629] irq event stamp: 70302
[ 41.252050] hardirqs last enabled at (70302): [<c0057c98>]
__getnstimeofday+0x15c/0x178
[ 41.260193] hardirqs last disabled at (70301): [<c0057b64>]
__getnstimeofday+0x28/0x178
[ 41.268243] softirqs last enabled at (70208): [<c001a158>]
__do_softirq+0x198/0x2c4
[ 41.276049] softirqs last disabled at (70217): [<c001a640>]
irq_exit+0xa4/0xf8
[ 41.283309]
[ 41.283309] other info that might help us debug this:
[ 41.289856] Possible unsafe locking scenario:
[ 41.289856]
[ 41.295793] CPU0
[ 41.298250] ----
[ 41.300706] lock(&(&sk->sk_dst_lock)->rlock);
[ 41.305277] <Interrupt>
[ 41.307908] lock(&(&sk->sk_dst_lock)->rlock);
[ 41.312652]
[ 41.312652] *** DEADLOCK ***
[ 41.312652]
[ 41.318605] 2 locks held by connmand/337:
[ 41.322628] #0: (rcu_read_lock){.+.+..}, at: [<c0386648>]
__netif_receive_skb_core+0x34/0x5e0
[ 41.331445] #1: (rcu_read_lock){.+.+..}, at: [<c03abf80>]
ip_local_deliver+0x5c/0x30c
[ 41.339559]
[ 41.339559] stack backtrace:
[ 41.343959] CPU: 0 PID: 337 Comm: connmand Not tainted
3.13.0-rc4-00018-g3b78c2f-dirty #8
[ 41.352208] [<c000d970>] (unwind_backtrace+0x0/0xf0) from
[<c000bd84>] (show_stack+0x10/0x14)
[ 41.360797] [<c000bd84>] (show_stack+0x10/0x14) from [<c0463cb4>]
(print_usage_bug.part.27+0x218/0x280)
[ 41.370251] [<c0463cb4>] (print_usage_bug.part.27+0x218/0x280) from
[<c0046308>] (mark_lock+0x288/0x668)
[ 41.379784] [<c0046308>] (mark_lock+0x288/0x668) from [<c0046c80>]
(__lock_acquire+0x598/0x1a64)
[ 41.388620] [<c0046c80>] (__lock_acquire+0x598/0x1a64) from
[<c0048694>] (lock_acquire+0x9c/0x104)
[ 41.397639] [<c0048694>] (lock_acquire+0x9c/0x104) from [<c046a690>]
(_raw_spin_lock+0x28/0x38)
[ 41.406390] [<c046a690>] (_raw_spin_lock+0x28/0x38) from [<c03d8088>]
(__udp4_lib_rcv+0x7e0/0x8a8)
[ 41.415399] [<c03d8088>] (__udp4_lib_rcv+0x7e0/0x8a8) from
[<c03abfec>] (ip_local_deliver+0xc8/0x30c)
[ 41.424667] [<c03abfec>] (ip_local_deliver+0xc8/0x30c) from
[<c03ac58c>] (ip_rcv+0x35c/0x74c)
[ 41.433247] [<c03ac58c>] (ip_rcv+0x35c/0x74c) from [<c03868ec>]
(__netif_receive_skb_core+0x2d8/0x5e0)
[ 41.442611] [<c03868ec>] (__netif_receive_skb_core+0x2d8/0x5e0) from
[<c03894ac>] (napi_gro_receive+0x74/0xa0)
[ 41.452675] [<c03894ac>] (napi_gro_receive+0x74/0xa0) from
[<c02d5f50>] (fec_enet_rx_napi+0x304/0x704)
[ 41.462037] [<c02d5f50>] (fec_enet_rx_napi+0x304/0x704) from
[<c038918c>] (net_rx_action+0xc0/0x20c)
[ 41.471235] [<c038918c>] (net_rx_action+0xc0/0x20c) from [<c001a0ac>]
(__do_softirq+0xec/0x2c4)
[ 41.479987] [<c001a0ac>] (__do_softirq+0xec/0x2c4) from [<c001a640>]
(irq_exit+0xa4/0xf8)
[ 41.488208] [<c001a640>] (irq_exit+0xa4/0xf8) from [<c0009e44>]
(handle_IRQ+0x34/0x84)
[ 41.496172] [<c0009e44>] (handle_IRQ+0x34/0x84) from [<c000c9c4>]
(__irq_usr+0x44/0x60)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Lockdep warning
@ 2008-03-06 12:14 Szekeres István
0 siblings, 0 replies; 13+ messages in thread
From: Szekeres István @ 2008-03-06 12:14 UTC (permalink / raw)
To: linux-kernel; +Cc: a.p.zijlstra, mingo
Found this on my computer after an uptime of 7 days. I don't know if
it is harmless or not. "dirty" is only because of an uncommitted HID
input quirk entry.
Config is available if needed.
------------[ cut here ]------------
WARNING: at kernel/lockdep.c:2662 check_flags+0x13b/0x160()
Modules linked in: tsl2550 pcf8591 pcf8575 pcf8574 max6875 eeprom
ds1682 i2c_via i2c_algo_bit i2c_dev nls_iso8859_1 nls_cp437 vfat fat
nls_base sg sd_mod usb_storage libusual usbhid rfcomm l2cap bluetooth
video output sbs sbshc container dock backlight ac battery joydev
evdev 8250_pnp 8250 serial_core psmouse rtc serio_raw pcspkr
snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_page_alloc
snd_mpu401_uart snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq
snd_timer snd_seq_device snd soundcore i2c_viapro i2c_core hid button
floppy ehci_hcd uhci_hcd usbcore dm_mirror dm_snapshot dm_mod unix
thermal processor fan fuse [last unloaded: usbhid]
Pid: 24638, comm: totem Not tainted 2.6.25-rc3pista-00081-g7704a8b-dirty #14
[warn_on_slowpath+84/112] warn_on_slowpath+0x54/0x70
[native_calculate_cpu_khz+240/352] ? native_calculate_cpu_khz+0xf0/0x160
[unqueue_me+63/128] ? unqueue_me+0x3f/0x80
[_spin_unlock+39/80] ? _spin_unlock+0x27/0x50
[unqueue_me+71/128] ? unqueue_me+0x47/0x80
[futex_wait+566/768] ? futex_wait+0x236/0x300
[check_flags+315/352] check_flags+0x13b/0x160
[lock_acquire+65/160] lock_acquire+0x41/0xa0
[down_read+61/128] down_read+0x3d/0x80
[futex_wake+46/240] ? futex_wake+0x2e/0xf0
[futex_wake+46/240] futex_wake+0x2e/0xf0
[do_futex+163/2688] do_futex+0xa3/0xa80
[do_notify_resume+97/1968] ? do_notify_resume+0x61/0x7b0
[sysenter_past_esp+157/165] ? sysenter_past_esp+0x9d/0xa5
[search_exception_tables+23/48] ? search_exception_tables+0x17/0x30
[fixup_exception+14/48] ? fixup_exception+0xe/0x30
[do_general_protection+343/656] ? do_general_protection+0x157/0x290
[ktime_get_ts+59/64] ? ktime_get_ts+0x3b/0x40
[ktime_get+17/48] ? ktime_get+0x11/0x30
[sys_futex+138/240] sys_futex+0x8a/0xf0
[sysenter_past_esp+95/165] sysenter_past_esp+0x5f/0xa5
=======================
---[ end trace cf60772f91bc8ecf ]---
possible reason: unannotated irqs-on.
irq event stamp: 21512
hardirqs last enabled at (21511): [sysenter_past_esp+154/165]
sysenter_past_esp+0x9a/0xa5
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: lockdep warning
2008-02-22 16:32 ` Anders Eriksson
@ 2008-02-22 17:01 ` Jiri Kosina
0 siblings, 0 replies; 13+ messages in thread
From: Jiri Kosina @ 2008-02-22 17:01 UTC (permalink / raw)
To: Anders Eriksson, davem; +Cc: linux-kernel, netdev
On Fri, 22 Feb 2008, Anders Eriksson wrote:
> > > Any chance that
> > > git revert 69cc64d8d92
> > > makes this report go away?
> I've tested the patch and I no longer get that lock thing in my syslog.
Thanks for verification.
Hmm, I don't immediately see how this patch could make neigh->lock owner
to change between lock and unlock ... I have skimmed through the solicit
methods, and they don't seem to be doing anything nasty to neigh ...
The scenario I was thinking about is that before 69cc64d8d92, if any of
the _solicit methods could do anything bad to neigh struct, this warning
wouldn't trigger, because the lock has been dropped before calling
_solicit() and reacquired later, so no mismatch on ->current could happen,
but now as long as the lock is held during _solicit() call, this would
trigger on the next unlock.
But I am not able to see anything like that in the code. Dave, do you have
any idea? (the thread started at http://lkml.org/lkml/2008/2/22/105).
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: lockdep warning
2008-02-22 13:20 ` Jiri Kosina
@ 2008-02-22 16:32 ` Anders Eriksson
2008-02-22 17:01 ` Jiri Kosina
0 siblings, 1 reply; 13+ messages in thread
From: Anders Eriksson @ 2008-02-22 16:32 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Anders Eriksson, linux-kernel, netdev
jkosina@suse.cz said:
> > Any chance that
> > git revert 69cc64d8d92
> > makes this report go away?
I've tested the patch and I no longer get that lock thing in my syslog.
/A
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: lockdep warning
2008-02-22 13:16 ` Anders Eriksson
@ 2008-02-22 13:20 ` Jiri Kosina
2008-02-22 16:32 ` Anders Eriksson
0 siblings, 1 reply; 13+ messages in thread
From: Jiri Kosina @ 2008-02-22 13:20 UTC (permalink / raw)
To: Anders Eriksson; +Cc: linux-kernel, netdev
On Fri, 22 Feb 2008, Anders Eriksson wrote:
> > This needs to be CCed to netdev.
> > Any chance that
> > git revert 69cc64d8d92
> > makes this report go away?
> I'll have to install a git repo to check, or maybe you can send me the diff to
> reverse vs. 2.6.25-rc2?
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 7bb6a9a..a16cf1e 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -834,12 +834,18 @@ static void neigh_timer_handler(unsigned long arg)
}
if (neigh->nud_state & (NUD_INCOMPLETE | NUD_PROBE)) {
struct sk_buff *skb = skb_peek(&neigh->arp_queue);
-
+ /* keep skb alive even if arp_queue overflows */
+ if (skb)
+ skb_get(skb);
+ write_unlock(&neigh->lock);
neigh->ops->solicit(neigh, skb);
atomic_inc(&neigh->probes);
- }
+ if (skb)
+ kfree_skb(skb);
+ } else {
out:
- write_unlock(&neigh->lock);
+ write_unlock(&neigh->lock);
+ }
if (notify)
neigh_update_notify(neigh);
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index c663fa5..8e17f65 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -368,6 +368,7 @@ static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb)
if (!(neigh->nud_state&NUD_VALID))
printk(KERN_DEBUG "trying to ucast probe in NUD_INVALID\n");
dst_ha = neigh->ha;
+ read_lock_bh(&neigh->lock);
} else if ((probes -= neigh->parms->app_probes) < 0) {
#ifdef CONFIG_ARPD
neigh_app_ns(neigh);
@@ -377,6 +378,8 @@ static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb)
arp_send(ARPOP_REQUEST, ETH_P_ARP, target, dev, saddr,
dst_ha, dev->dev_addr, NULL);
+ if (dst_ha)
+ read_unlock_bh(&neigh->lock);
}
static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: lockdep warning
2008-02-22 11:16 ` Jiri Kosina
@ 2008-02-22 13:16 ` Anders Eriksson
2008-02-22 13:20 ` Jiri Kosina
0 siblings, 1 reply; 13+ messages in thread
From: Anders Eriksson @ 2008-02-22 13:16 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Anders Eriksson, linux-kernel, netdev
jkosina@suse.cz said:
> This needs to be CCed to netdev.
> Any chance that
> git revert 69cc64d8d92
> makes this report go away?
I'll have to install a git repo to check, or maybe you can send me the diff to
reverse vs. 2.6.25-rc2?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: lockdep warning
2008-02-22 10:40 lockdep warning Anders Eriksson
@ 2008-02-22 11:16 ` Jiri Kosina
2008-02-22 13:16 ` Anders Eriksson
0 siblings, 1 reply; 13+ messages in thread
From: Jiri Kosina @ 2008-02-22 11:16 UTC (permalink / raw)
To: Anders Eriksson; +Cc: linux-kernel, netdev
On Fri, 22 Feb 2008, Anders Eriksson wrote:
> I found this is a newly booted 2.6.25-rc2's syslog.
> Feb 21 20:46:33 tippex BUG: rwlock wrong owner on CPU#0, runscript.sh/2633, d2c04084
> Feb 21 20:46:33 tippex Pid: 2633, comm: runscript.sh Not tainted 2.6.25-rc2 #3
> Feb 21 20:46:33 tippex [<c02342d0>] rwlock_bug+0x50/0x60
> Feb 21 20:46:33 tippex [<c0234356>] _raw_write_unlock+0x56/0x60
> Feb 21 20:46:33 tippex [<c040365d>] _write_unlock+0x1d/0x50
> Feb 21 20:46:33 tippex [<c03289be>] neigh_timer_handler+0x18e/0x2d0
> Feb 21 20:46:33 tippex [<c0125449>] run_timer_softirq+0x119/0x180
> Feb 21 20:46:33 tippex [<c013856d>] ? lock_release_holdtime+0x5d/0x80
> Feb 21 20:46:33 tippex [<c0328830>] ? neigh_timer_handler+0x0/0x2d0
> Feb 21 20:46:33 tippex [<c0121a64>] __do_softirq+0x54/0xb0
> Feb 21 20:46:33 tippex [<c0121af5>] do_softirq+0x35/0x40
> Feb 21 20:46:33 tippex [<c0121cb4>] irq_exit+0x44/0x50
> Feb 21 20:46:33 tippex [<c0105757>] do_IRQ+0x47/0x80
> Feb 21 20:46:33 tippex [<c01039c3>] common_interrupt+0x23/0x28
> Feb 21 20:46:33 tippex =======================
This needs to be CCed to netdev.
Any chance that
git revert 69cc64d8d92
makes this report go away?
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 13+ messages in thread
* lockdep warning
@ 2008-02-22 10:40 Anders Eriksson
2008-02-22 11:16 ` Jiri Kosina
0 siblings, 1 reply; 13+ messages in thread
From: Anders Eriksson @ 2008-02-22 10:40 UTC (permalink / raw)
To: linux-kernel
I found this is a newly booted 2.6.25-rc2's syslog.
Feb 21 20:46:33 tippex BUG: rwlock wrong owner on CPU#0, runscript.sh/2633, d2c04084
Feb 21 20:46:33 tippex Pid: 2633, comm: runscript.sh Not tainted 2.6.25-rc2 #3
Feb 21 20:46:33 tippex [<c02342d0>] rwlock_bug+0x50/0x60
Feb 21 20:46:33 tippex [<c0234356>] _raw_write_unlock+0x56/0x60
Feb 21 20:46:33 tippex [<c040365d>] _write_unlock+0x1d/0x50
Feb 21 20:46:33 tippex [<c03289be>] neigh_timer_handler+0x18e/0x2d0
Feb 21 20:46:33 tippex [<c0125449>] run_timer_softirq+0x119/0x180
Feb 21 20:46:33 tippex [<c013856d>] ? lock_release_holdtime+0x5d/0x80
Feb 21 20:46:33 tippex [<c0328830>] ? neigh_timer_handler+0x0/0x2d0
Feb 21 20:46:33 tippex [<c0121a64>] __do_softirq+0x54/0xb0
Feb 21 20:46:33 tippex [<c0121af5>] do_softirq+0x35/0x40
Feb 21 20:46:33 tippex [<c0121cb4>] irq_exit+0x44/0x50
Feb 21 20:46:33 tippex [<c0105757>] do_IRQ+0x47/0x80
Feb 21 20:46:33 tippex [<c01039c3>] common_interrupt+0x23/0x28
Feb 21 20:46:33 tippex =======================
It doesn't make any sens to me but I guess it does to others.
The other bad thing is that the machine hangs shortly after boot bitching
about 'hdb: lost interrupt' on the console. Kown problem?
/A
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-12-19 14:14 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-26 17:29 Lockdep warning Larry Finger
2011-08-26 20:18 ` Shaun Ruffell
-- strict thread matches above, loose matches on Subject: below --
2013-12-19 13:36 Jonas Bonn
2013-12-19 14:02 ` Borislav Petkov
2013-12-19 14:04 ` Jonas Bonn
2013-12-19 14:14 ` Borislav Petkov
2008-03-06 12:14 Szekeres István
2008-02-22 10:40 lockdep warning Anders Eriksson
2008-02-22 11:16 ` Jiri Kosina
2008-02-22 13:16 ` Anders Eriksson
2008-02-22 13:20 ` Jiri Kosina
2008-02-22 16:32 ` Anders Eriksson
2008-02-22 17:01 ` Jiri Kosina
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.