* Locking problem reported for mainline
@ 2011-01-10 5:03 Larry Finger
2011-01-10 16:06 ` Stanislaw Gruszka
2011-01-10 18:13 ` Christian Lamparter
0 siblings, 2 replies; 8+ messages in thread
From: Larry Finger @ 2011-01-10 5:03 UTC (permalink / raw)
To: wireless
I have updated my "Linus" tree to the latest state as of Jan. 9, 2011. Uname -r
reports
2.6.37-Linus-03737-g0c21e3a-dirty
The logged messages are listed below.
Thanks,
Larry
=======================================================================
[ 25.660371] =================================
[ 25.660376] [ INFO: inconsistent lock state ]
[ 25.660379] 2.6.37-Linus-03737-g0c21e3a-dirty #251
[ 25.660382] ---------------------------------
[ 25.660384] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[ 25.660388] kworker/0:0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[ 25.660390] (&(&list->lock)->rlock#5){?.-...}, at: [<ffffffff812a2746>]
skb_queue_tail+0x26/0x60
[ 25.660401] {HARDIRQ-ON-W} state was registered at:
[ 25.660403] [<ffffffff8107f305>] __lock_acquire+0xb25/0x1cc0
[ 25.660409] [<ffffffff81080a73>] lock_acquire+0x93/0x130
[ 25.660413] [<ffffffff813446cc>] _raw_spin_lock+0x2c/0x40
[ 25.660418] [<ffffffffa02b3777>] ieee80211_rx_handlers+0x27/0x1c80 [mac80211]
[ 25.660444] [<ffffffffa02b5608>]
ieee80211_prepare_and_rx_handle+0x238/0x900 [mac80211]
[ 25.660455] [<ffffffffa02b5fea>] ieee80211_rx+0x31a/0x940 [mac80211]
[ 25.660465] [<ffffffffa029cd51>] ieee80211_tasklet_handler+0xc1/0xd0 [mac80211]
[ 25.660474] [<ffffffff8104f993>] tasklet_action+0x73/0x120
[ 25.660479] [<ffffffff8105048e>] __do_softirq+0xce/0x200
[ 25.660483] [<ffffffff81003ccc>] call_softirq+0x1c/0x30
[ 25.660488] [<ffffffff81005e25>] do_softirq+0x85/0xc0
[ 25.660492] [<ffffffff810506cd>] irq_exit+0x8d/0xa0
[ 25.660496] [<ffffffff81005971>] do_IRQ+0x61/0xe0
[ 25.660500] [<ffffffff813452d3>] ret_from_intr+0x0/0xf
[ 25.660504] [<ffffffff81179cd7>] sysfs_permission+0x47/0x80
[ 25.660510] [<ffffffff81126bfa>] link_path_walk+0x1ea/0xdb0
[ 25.660515] [<ffffffff81127568>] link_path_walk+0xb58/0xdb0
[ 25.660519] [<ffffffff81127ab6>] do_path_lookup+0x56/0x130
[ 25.660523] [<ffffffff81127f92>] user_path_at+0x52/0xa0
[ 25.660526] [<ffffffff8111e634>] vfs_fstatat+0x34/0x70
[ 25.660532] [<ffffffff8111e6a6>] vfs_stat+0x16/0x20
[ 25.660536] [<ffffffff8111ea4f>] sys_newstat+0x1f/0x40
[ 25.660540] [<ffffffff81002d7b>] system_call_fastpath+0x16/0x1b
[ 25.660546] irq event stamp: 393974
[ 25.660548] hardirqs last enabled at (393971): [<ffffffff8100c03a>]
default_idle+0x5a/0xf0
[ 25.660553] hardirqs last disabled at (393972): [<ffffffff81345227>]
save_args+0x67/0x70
[ 25.660557] softirqs last enabled at (393974): [<ffffffff810501de>]
_local_bh_enable+0xe/0x10
[ 25.660562] softirqs last disabled at (393973): [<ffffffff8105062d>]
irq_enter+0x6d/0x80
[ 25.660566]
[ 25.660567] other info that might help us debug this:
[ 25.660570] 1 lock held by kworker/0:0/0:
[ 25.660572] #0: (&(&rtlpriv->locks.irq_th_lock)->rlock){-.-...}, at:
[<ffffffffa02f0daf>] _rtl_pci_interrupt+0x5f/0x890 [rtlwifi]
[ 25.660585]
[ 25.660586] stack backtrace:
[ 25.660589] Pid: 0, comm: kworker/0:0 Tainted: G W
2.6.37-Linus-03737-g0c21e3a-dirty #251
[ 25.660592] Call Trace:
[ 25.660594] <IRQ> [<ffffffff8107e152>] ? print_usage_bug+0x182/0x1d0
[ 25.660601] [<ffffffff8107e571>] ? mark_lock+0x3d1/0x640
[ 25.660605] [<ffffffff8107f3bd>] ? __lock_acquire+0xbdd/0x1cc0
[ 25.660610] [<ffffffff811d2aae>] ? check_unmap+0x3be/0x7e0
[ 25.660615] [<ffffffff8107bc2d>] ? trace_hardirqs_off+0xd/0x10
[ 25.660619] [<ffffffff81080a73>] ? lock_acquire+0x93/0x130
[ 25.660622] [<ffffffff812a2746>] ? skb_queue_tail+0x26/0x60
[ 25.660627] [<ffffffff810af978>] ? rcu_start_gp+0x258/0x350
[ 25.660630] [<ffffffff813447cc>] ? _raw_spin_lock_irqsave+0x3c/0x60
[ 25.660634] [<ffffffff812a2746>] ? skb_queue_tail+0x26/0x60
[ 25.660637] [<ffffffff812a2746>] ? skb_queue_tail+0x26/0x60
[ 25.660647] [<ffffffffa029e166>] ? ieee80211_tx_status_irqsafe+0x36/0xb0
[mac80211]
[ 25.660653] [<ffffffffa02f0b90>] ? _rtl_pci_tx_isr+0x180/0x340 [rtlwifi]
[ 25.660659] [<ffffffffa02f0e75>] ? _rtl_pci_interrupt+0x125/0x890 [rtlwifi]
[ 25.660665] [<ffffffff810ab299>] ? handle_IRQ_event+0x49/0x170
[ 25.660670] [<ffffffff810ada52>] ? handle_fasteoi_irq+0x92/0x110
[ 25.660674] [<ffffffff81005d44>] ? handle_irq+0x44/0xa0
[ 25.660677] [<ffffffff81005968>] ? do_IRQ+0x58/0xe0
[ 25.660681] [<ffffffff813452d3>] ? ret_from_intr+0x0/0xf
[ 25.660683] <EOI> [<ffffffff8100c03c>] ? default_idle+0x5c/0xf0
[ 25.660690] [<ffffffff8100c03a>] ? default_idle+0x5a/0xf0
[ 25.660694] [<ffffffff8100c124>] ? c1e_idle+0x54/0x100
[ 25.660698] [<ffffffff810011eb>] ? cpu_idle+0x5b/0x120
[ 25.660703] [<ffffffff8133dd72>] ? start_secondary+0x190/0x194
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Locking problem reported for mainline
2011-01-10 5:03 Locking problem reported for mainline Larry Finger
@ 2011-01-10 16:06 ` Stanislaw Gruszka
2011-01-10 18:13 ` Christian Lamparter
1 sibling, 0 replies; 8+ messages in thread
From: Stanislaw Gruszka @ 2011-01-10 16:06 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
On Sun, Jan 09, 2011 at 11:03:05PM -0600, Larry Finger wrote:
> I have updated my "Linus" tree to the latest state as of Jan. 9, 2011. Uname -r
> reports
>
> 2.6.37-Linus-03737-g0c21e3a-dirty
>
> The logged messages are listed below.
I think this is a false positive, because for lockdep
local->rx_skb_queue->lock and local->skb_queue->lock
is the same lock (struct sk_buff_head->lock). Hence warn when we do
not spin_lock_irq in ieee80211_rx_handlers(), but take lock
from interrupt handler in ieee80211_tx_status_irqsafe()-> skb_queue_tail()
Stanislaw
> =======================================================================
>
> [ 25.660371] =================================
> [ 25.660376] [ INFO: inconsistent lock state ]
> [ 25.660379] 2.6.37-Linus-03737-g0c21e3a-dirty #251
> [ 25.660382] ---------------------------------
> [ 25.660384] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> [ 25.660388] kworker/0:0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
> [ 25.660390] (&(&list->lock)->rlock#5){?.-...}, at: [<ffffffff812a2746>]
> skb_queue_tail+0x26/0x60
> [ 25.660401] {HARDIRQ-ON-W} state was registered at:
> [ 25.660403] [<ffffffff8107f305>] __lock_acquire+0xb25/0x1cc0
> [ 25.660409] [<ffffffff81080a73>] lock_acquire+0x93/0x130
> [ 25.660413] [<ffffffff813446cc>] _raw_spin_lock+0x2c/0x40
> [ 25.660418] [<ffffffffa02b3777>] ieee80211_rx_handlers+0x27/0x1c80 [mac80211]
> [ 25.660444] [<ffffffffa02b5608>]
> ieee80211_prepare_and_rx_handle+0x238/0x900 [mac80211]
> [ 25.660455] [<ffffffffa02b5fea>] ieee80211_rx+0x31a/0x940 [mac80211]
> [ 25.660465] [<ffffffffa029cd51>] ieee80211_tasklet_handler+0xc1/0xd0 [mac80211]
> [ 25.660474] [<ffffffff8104f993>] tasklet_action+0x73/0x120
> [ 25.660479] [<ffffffff8105048e>] __do_softirq+0xce/0x200
> [ 25.660483] [<ffffffff81003ccc>] call_softirq+0x1c/0x30
> [ 25.660488] [<ffffffff81005e25>] do_softirq+0x85/0xc0
> [ 25.660492] [<ffffffff810506cd>] irq_exit+0x8d/0xa0
> [ 25.660496] [<ffffffff81005971>] do_IRQ+0x61/0xe0
> [ 25.660500] [<ffffffff813452d3>] ret_from_intr+0x0/0xf
> [ 25.660504] [<ffffffff81179cd7>] sysfs_permission+0x47/0x80
> [ 25.660510] [<ffffffff81126bfa>] link_path_walk+0x1ea/0xdb0
> [ 25.660515] [<ffffffff81127568>] link_path_walk+0xb58/0xdb0
> [ 25.660519] [<ffffffff81127ab6>] do_path_lookup+0x56/0x130
> [ 25.660523] [<ffffffff81127f92>] user_path_at+0x52/0xa0
> [ 25.660526] [<ffffffff8111e634>] vfs_fstatat+0x34/0x70
> [ 25.660532] [<ffffffff8111e6a6>] vfs_stat+0x16/0x20
> [ 25.660536] [<ffffffff8111ea4f>] sys_newstat+0x1f/0x40
> [ 25.660540] [<ffffffff81002d7b>] system_call_fastpath+0x16/0x1b
> [ 25.660546] irq event stamp: 393974
> [ 25.660548] hardirqs last enabled at (393971): [<ffffffff8100c03a>]
> default_idle+0x5a/0xf0
> [ 25.660553] hardirqs last disabled at (393972): [<ffffffff81345227>]
> save_args+0x67/0x70
> [ 25.660557] softirqs last enabled at (393974): [<ffffffff810501de>]
> _local_bh_enable+0xe/0x10
> [ 25.660562] softirqs last disabled at (393973): [<ffffffff8105062d>]
> irq_enter+0x6d/0x80
> [ 25.660566]
> [ 25.660567] other info that might help us debug this:
> [ 25.660570] 1 lock held by kworker/0:0/0:
> [ 25.660572] #0: (&(&rtlpriv->locks.irq_th_lock)->rlock){-.-...}, at:
> [<ffffffffa02f0daf>] _rtl_pci_interrupt+0x5f/0x890 [rtlwifi]
> [ 25.660585]
> [ 25.660586] stack backtrace:
> [ 25.660589] Pid: 0, comm: kworker/0:0 Tainted: G W
> 2.6.37-Linus-03737-g0c21e3a-dirty #251
> [ 25.660592] Call Trace:
> [ 25.660594] <IRQ> [<ffffffff8107e152>] ? print_usage_bug+0x182/0x1d0
> [ 25.660601] [<ffffffff8107e571>] ? mark_lock+0x3d1/0x640
> [ 25.660605] [<ffffffff8107f3bd>] ? __lock_acquire+0xbdd/0x1cc0
> [ 25.660610] [<ffffffff811d2aae>] ? check_unmap+0x3be/0x7e0
> [ 25.660615] [<ffffffff8107bc2d>] ? trace_hardirqs_off+0xd/0x10
> [ 25.660619] [<ffffffff81080a73>] ? lock_acquire+0x93/0x130
> [ 25.660622] [<ffffffff812a2746>] ? skb_queue_tail+0x26/0x60
> [ 25.660627] [<ffffffff810af978>] ? rcu_start_gp+0x258/0x350
> [ 25.660630] [<ffffffff813447cc>] ? _raw_spin_lock_irqsave+0x3c/0x60
> [ 25.660634] [<ffffffff812a2746>] ? skb_queue_tail+0x26/0x60
> [ 25.660637] [<ffffffff812a2746>] ? skb_queue_tail+0x26/0x60
> [ 25.660647] [<ffffffffa029e166>] ? ieee80211_tx_status_irqsafe+0x36/0xb0
> [mac80211]
> [ 25.660653] [<ffffffffa02f0b90>] ? _rtl_pci_tx_isr+0x180/0x340 [rtlwifi]
> [ 25.660659] [<ffffffffa02f0e75>] ? _rtl_pci_interrupt+0x125/0x890 [rtlwifi]
> [ 25.660665] [<ffffffff810ab299>] ? handle_IRQ_event+0x49/0x170
> [ 25.660670] [<ffffffff810ada52>] ? handle_fasteoi_irq+0x92/0x110
> [ 25.660674] [<ffffffff81005d44>] ? handle_irq+0x44/0xa0
> [ 25.660677] [<ffffffff81005968>] ? do_IRQ+0x58/0xe0
> [ 25.660681] [<ffffffff813452d3>] ? ret_from_intr+0x0/0xf
> [ 25.660683] <EOI> [<ffffffff8100c03c>] ? default_idle+0x5c/0xf0
> [ 25.660690] [<ffffffff8100c03a>] ? default_idle+0x5a/0xf0
> [ 25.660694] [<ffffffff8100c124>] ? c1e_idle+0x54/0x100
> [ 25.660698] [<ffffffff810011eb>] ? cpu_idle+0x5b/0x120
> [ 25.660703] [<ffffffff8133dd72>] ? start_secondary+0x190/0x194
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Locking problem reported for mainline
2011-01-10 5:03 Locking problem reported for mainline Larry Finger
2011-01-10 16:06 ` Stanislaw Gruszka
@ 2011-01-10 18:13 ` Christian Lamparter
2011-01-10 19:11 ` Larry Finger
1 sibling, 1 reply; 8+ messages in thread
From: Christian Lamparter @ 2011-01-10 18:13 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
On Monday 10 January 2011 06:03:05 Larry Finger wrote:
> I have updated my "Linus" tree to the latest state as of Jan. 9, 2011.
> Uname -r reports
>
> 2.6.37-Linus-03737-g0c21e3a-dirty
>
> The logged messages are listed below.
>
> [ 25.660371] =================================
> [ 25.660376] [ INFO: inconsistent lock state ]
> [ 25.660379] 2.6.37-Linus-03737-g0c21e3a-dirty #251
> [ 25.660382] ---------------------------------
> [ 25.660384] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> [ 25.660388] kworker/0:0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
> [ 25.660390] (&(&list->lock)->rlock#5){?.-...}, at: [<ffffffff812a2746>]
> skb_queue_tail+0x26/0x60
> [ 25.660401] {HARDIRQ-ON-W} state was registered at:
> [ 25.660403] [<ffffffff8107f305>] __lock_acquire+0xb25/0x1cc0
> [ 25.660409] [<ffffffff81080a73>] lock_acquire+0x93/0x130
> [ 25.660413] [<ffffffff813446cc>] _raw_spin_lock+0x2c/0x40
> [ 25.660418] [<ffffffffa02b3777>] ieee80211_rx_handlers+0x27/0x1c80 [mac80211]
> [ 25.660444] [<ffffffffa02b5608>]
> ieee80211_prepare_and_rx_handle+0x238/0x900 [mac80211]
> [ 25.660455] [<ffffffffa02b5fea>] ieee80211_rx+0x31a/0x940 [mac80211]
> [ 25.660465] [<ffffffffa029cd51>] ieee80211_tasklet_handler+0xc1/0xd0 [mac80211]
> [ 25.660474] [<ffffffff8104f993>] tasklet_action+0x73/0x120
> [ 25.660479] [<ffffffff8105048e>] __do_softirq+0xce/0x200
> [ 25.660546] irq event stamp: 393974
> [ 25.660548] hardirqs last enabled at (393971): [<ffffffff8100c03a>]
> default_idle+0x5a/0xf0
> [ 25.660553] hardirqs last disabled at (393972): [<ffffffff81345227>]
> save_args+0x67/0x70
> [ 25.660557] softirqs last enabled at (393974): [<ffffffff810501de>]
> _local_bh_enable+0xe/0x10
> [ 25.660562] softirqs last disabled at (393973): [<ffffffff8105062d>]
> irq_enter+0x6d/0x80
> [ 25.660566]
> [ 25.660567] other info that might help us debug this:
> [ 25.660570] 1 lock held by kworker/0:0/0:
> [ 25.660572] #0: (&(&rtlpriv->locks.irq_th_lock)->rlock){-.-...}, at:
> [<ffffffffa02f0daf>] _rtl_pci_interrupt+0x5f/0x890 [rtlwifi]
> [ 25.660585]
> [ 25.660586] stack backtrace:
> [ 25.660589] Pid: 0, comm: kworker/0:0 Tainted: G W
> 2.6.37-Linus-03737-g0c21e3a-dirty #251
> [ 25.660592] Call Trace:
> [ 25.660594] <IRQ> [<ffffffff8107e152>] ? print_usage_bug+0x182/0x1d0
> [ 25.660601] [<ffffffff8107e571>] ? mark_lock+0x3d1/0x640
> [ 25.660605] [<ffffffff8107f3bd>] ? __lock_acquire+0xbdd/0x1cc0
> [ 25.660610] [<ffffffff811d2aae>] ? check_unmap+0x3be/0x7e0
> [ 25.660615] [<ffffffff8107bc2d>] ? trace_hardirqs_off+0xd/0x10
> [ 25.660619] [<ffffffff81080a73>] ? lock_acquire+0x93/0x130
> [ 25.660622] [<ffffffff812a2746>] ? skb_queue_tail+0x26/0x60
> [ 25.660627] [<ffffffff810af978>] ? rcu_start_gp+0x258/0x350
> [ 25.660630] [<ffffffff813447cc>] ? _raw_spin_lock_irqsave+0x3c/0x60
> [ 25.660634] [<ffffffff812a2746>] ? skb_queue_tail+0x26/0x60
> [ 25.660637] [<ffffffff812a2746>] ? skb_queue_tail+0x26/0x60
> [ 25.660647] [<ffffffffa029e166>] ? ieee80211_tx_status_irqsafe+0x36/0xb0
> [mac80211]
> [ 25.660653] [<ffffffffa02f0b90>] ? _rtl_pci_tx_isr+0x180/0x340 [rtlwifi]
> [ 25.660659] [<ffffffffa02f0e75>] ? _rtl_pci_interrupt+0x125/0x890 [rtlwifi]
Does this patch help?
---
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index a6701ed..8f13a83 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -549,7 +549,9 @@ static void ieee80211_release_reorder_frame(struct ieee80211_hw *hw,
tid_agg_rx->reorder_buf[index] = NULL;
status = IEEE80211_SKB_RXCB(skb);
status->rx_flags |= IEEE80211_RX_DEFERRED_RELEASE;
- skb_queue_tail(&local->rx_skb_queue, skb);
+ spin_lock(&rx->local->rx_skb_queue.lock);
+ __skb_queue_tail(&local->rx_skb_queue, skb);
+ spin_unlock(&rx->local->rx_skb_queue.lock);
no_frame:
tid_agg_rx->head_seq_num = seq_inc(tid_agg_rx->head_seq_num);
@@ -780,7 +782,9 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
return;
dont_reorder:
- skb_queue_tail(&local->rx_skb_queue, skb);
+ spin_lock(&rx->local->rx_skb_queue.lock);
+ __skb_queue_tail(&local->rx_skb_queue, skb);
+ spin_unlock(&rx->local->rx_skb_queue.lock);
}
static ieee80211_rx_result debug_noinline
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: Locking problem reported for mainline
2011-01-10 18:13 ` Christian Lamparter
@ 2011-01-10 19:11 ` Larry Finger
2011-01-10 19:18 ` Christian Lamparter
0 siblings, 1 reply; 8+ messages in thread
From: Larry Finger @ 2011-01-10 19:11 UTC (permalink / raw)
To: Christian Lamparter; +Cc: wireless
On 01/10/2011 12:13 PM, Christian Lamparter wrote:
> Does this patch help?
>
> ---
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index a6701ed..8f13a83 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -549,7 +549,9 @@ static void ieee80211_release_reorder_frame(struct ieee80211_hw *hw,
> tid_agg_rx->reorder_buf[index] = NULL;
> status = IEEE80211_SKB_RXCB(skb);
> status->rx_flags |= IEEE80211_RX_DEFERRED_RELEASE;
> - skb_queue_tail(&local->rx_skb_queue, skb);
> + spin_lock(&rx->local->rx_skb_queue.lock);
> + __skb_queue_tail(&local->rx_skb_queue, skb);
> + spin_unlock(&rx->local->rx_skb_queue.lock);
>
> no_frame:
> tid_agg_rx->head_seq_num = seq_inc(tid_agg_rx->head_seq_num);
> @@ -780,7 +782,9 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
> return;
>
> dont_reorder:spin_lock(&rx->local->rx_skb_queue.lock);
> - skb_queue_tail(&local->rx_skb_queue, skb);
> + spin_lock(&rx->local->rx_skb_queue.lock);
> + __skb_queue_tail(&local->rx_skb_queue, skb);
> + spin_unlock(&rx->local->rx_skb_queue.lock);
> }
>
> static ieee80211_rx_result debug_noinline
Did not compile. In ieee80211_release_reorder_frame at lines 552 and 554, rx is
not defined.
Larry
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Locking problem reported for mainline
2011-01-10 19:11 ` Larry Finger
@ 2011-01-10 19:18 ` Christian Lamparter
2011-01-11 16:31 ` Larry Finger
0 siblings, 1 reply; 8+ messages in thread
From: Christian Lamparter @ 2011-01-10 19:18 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
On Monday 10 January 2011 20:11:38 Larry Finger wrote:
> On 01/10/2011 12:13 PM, Christian Lamparter wrote:
> > Does this patch help?
> >
> > ---
> > diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> > index a6701ed..8f13a83 100644
> > --- a/net/mac80211/rx.c
> > +++ b/net/mac80211/rx.c
>
> Did not compile. In ieee80211_release_reorder_frame at lines 552 and 554, rx is
> not defined.
>
Oops,
you are right. Fixed the copy&paste error, so this one should compile.
---
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index a6701ed..936b932 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -549,7 +549,9 @@ static void ieee80211_release_reorder_frame(struct ieee80211_hw *hw,
tid_agg_rx->reorder_buf[index] = NULL;
status = IEEE80211_SKB_RXCB(skb);
status->rx_flags |= IEEE80211_RX_DEFERRED_RELEASE;
- skb_queue_tail(&local->rx_skb_queue, skb);
+ spin_lock(&local->rx_skb_queue.lock);
+ __skb_queue_tail(&local->rx_skb_queue, skb);
+ spin_unlock(&local->rx_skb_queue.lock);
no_frame:
tid_agg_rx->head_seq_num = seq_inc(tid_agg_rx->head_seq_num);
@@ -780,7 +782,9 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
return;
dont_reorder:
- skb_queue_tail(&local->rx_skb_queue, skb);
+ spin_lock(&local->rx_skb_queue.lock);
+ __skb_queue_tail(&local->rx_skb_queue, skb);
+ spin_unlock(&local->rx_skb_queue.lock);
}
static ieee80211_rx_result debug_noinline
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: Locking problem reported for mainline
2011-01-10 19:18 ` Christian Lamparter
@ 2011-01-11 16:31 ` Larry Finger
2011-01-11 19:45 ` Bob Copeland
0 siblings, 1 reply; 8+ messages in thread
From: Larry Finger @ 2011-01-11 16:31 UTC (permalink / raw)
To: Christian Lamparter; +Cc: wireless
On 01/10/2011 01:18 PM, Christian Lamparter wrote:
> On Monday 10 January 2011 20:11:38 Larry Finger wrote:
>> On 01/10/2011 12:13 PM, Christian Lamparter wrote:
>>> Does this patch help?
>>>
>>> ---
>>> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
>>> index a6701ed..8f13a83 100644
>>> --- a/net/mac80211/rx.c
>>> +++ b/net/mac80211/rx.c
>>
>> Did not compile. In ieee80211_release_reorder_frame at lines 552 and 554, rx is
>> not defined.
>>
> Oops,
>
> you are right. Fixed the copy&paste error, so this one should compile.
No, the patch did not help.
Is there a document that explains what the meaning of these semantics?
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
kdostartupconfi/3502 [HC1[1]:SC0[0]:HE0:SE1] takes:
(&(&list->lock)->rlock#5){?.-...}, at: [<ffffffff812995c6>]
skb_queue_tail+0x26/0x60
{HARDIRQ-ON-W} state was registered at:
...
It appears that the problem is with rtlwifi, thus I need to sort it out. Google
has not been my friend in this case.
Thanks,
Larry
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Locking problem reported for mainline
2011-01-11 16:31 ` Larry Finger
@ 2011-01-11 19:45 ` Bob Copeland
2011-01-11 20:52 ` Larry Finger
0 siblings, 1 reply; 8+ messages in thread
From: Bob Copeland @ 2011-01-11 19:45 UTC (permalink / raw)
To: Larry Finger; +Cc: Christian Lamparter, wireless
On Tue, Jan 11, 2011 at 11:31 AM, Larry Finger
<Larry.Finger@lwfinger.net> wrote:
> Is there a document that explains what the meaning of these semantics?
>
> inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> kdostartupconfi/3502 [HC1[1]:SC0[0]:HE0:SE1] takes:
> (&(&list->lock)->rlock#5){?.-...}, at: [<ffffffff812995c6>]
> skb_queue_tail+0x26/0x60
> {HARDIRQ-ON-W} state was registered at:
I'm not sure about all the HC1[1]:SC0[0] etc stuff, but check out
Documentation/lockdep-design.txt for the basics.
In this case, someone took a lock with interrupts enabled (HARDIRQ-ON-W)
while someone else took it in a hard IRQ context (IN-HARDIRQ-W) where
they are normally disabled. The problem of course is:
cpu0:
spin_lock(&foo);
do some stuff protected by foo;
----> interrupt happens here
spin_lock(&foo); /* darn, deadlock! */
other stuff;
spin_unlock(&foo);
<----
spin_unlock(&foo);
Could be a missing _irqsave() if it's not, as Stanislaw suggested, a false
positive.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Locking problem reported for mainline
2011-01-11 19:45 ` Bob Copeland
@ 2011-01-11 20:52 ` Larry Finger
0 siblings, 0 replies; 8+ messages in thread
From: Larry Finger @ 2011-01-11 20:52 UTC (permalink / raw)
To: Bob Copeland; +Cc: Christian Lamparter, wireless
On 01/11/2011 01:45 PM, Bob Copeland wrote:
> On Tue, Jan 11, 2011 at 11:31 AM, Larry Finger
> <Larry.Finger@lwfinger.net> wrote:
>> Is there a document that explains what the meaning of these semantics?
>>
>> inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
>> kdostartupconfi/3502 [HC1[1]:SC0[0]:HE0:SE1] takes:
>> (&(&list->lock)->rlock#5){?.-...}, at: [<ffffffff812995c6>]
>> skb_queue_tail+0x26/0x60
>> {HARDIRQ-ON-W} state was registered at:
>
> I'm not sure about all the HC1[1]:SC0[0] etc stuff, but check out
> Documentation/lockdep-design.txt for the basics.
That one I had read.
> In this case, someone took a lock with interrupts enabled (HARDIRQ-ON-W)
> while someone else took it in a hard IRQ context (IN-HARDIRQ-W) where
> they are normally disabled. The problem of course is:
>
> cpu0:
> spin_lock(&foo);
> do some stuff protected by foo;
>
> ----> interrupt happens here
> spin_lock(&foo); /* darn, deadlock! */
> other stuff;
> spin_unlock(&foo);
> <----
>
> spin_unlock(&foo);
>
> Could be a missing _irqsave() if it's not, as Stanislaw suggested, a false
> positive.
I suspected the message meant mixed interrupts disabled/enabled, but thanks for
the confirmation.
Thanks,
Larry
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-01-11 20:52 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-10 5:03 Locking problem reported for mainline Larry Finger
2011-01-10 16:06 ` Stanislaw Gruszka
2011-01-10 18:13 ` Christian Lamparter
2011-01-10 19:11 ` Larry Finger
2011-01-10 19:18 ` Christian Lamparter
2011-01-11 16:31 ` Larry Finger
2011-01-11 19:45 ` Bob Copeland
2011-01-11 20:52 ` Larry Finger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).