* [PATCH] ath9k: fix panic caused by returning a descriptor we have queued for reuse
@ 2012-06-27 17:21 ` Tom Hughes
0 siblings, 0 replies; 6+ messages in thread
From: Tom Hughes @ 2012-06-27 17:21 UTC (permalink / raw)
To: linville
Cc: linux-wireless, ath9k-devel, mcgrof, jouni, vthiagar, senthilb,
Tom Hughes
Commit 3a2923e83c introduced a bug when a corrupt descriptor
is encountered - although the following descriptor is discarded
and returned to the queue for reuse the associated frame is
also returned for processing. This leads to a panic:
BUG: unable to handle kernel NULL pointer dereference at 000000000000003a
IP: [<ffffffffa02599a5>] ath_rx_tasklet+0x165/0x1b00 [ath9k]
Call Trace:
<IRQ>
[<ffffffff812d7fa0>] ? map_single+0x60/0x60
[<ffffffffa028f044>] ? ath9k_ioread32+0x34/0x90 [ath9k]
[<ffffffffa0292eec>] athk9k_tasklet+0xdc/0x160 [ath9k]
[<ffffffff8105e133>] tasklet_action+0x63/0xd0
[<ffffffff8105dbc0>] __do_softirq+0xc0/0x1e0
[<ffffffff8101a873>] ? native_sched_clock+0x13/0x80
[<ffffffff815f9d5c>] call_softirq+0x1c/0x30
[<ffffffff810151f5>] do_softirq+0x75/0xb0
[<ffffffff8105df95>] irq_exit+0xb5/0xc0
[<ffffffff815fa5b3>] do_IRQ+0x63/0xe0
[<ffffffff815f0cea>] common_interrupt+0x6a/0x6a
<EOI>
[<ffffffff8131840a>] ? intel_idle+0xea/0x150
[<ffffffff813183eb>] ? intel_idle+0xcb/0x150
[<ffffffff814a1db9>] cpuidle_enter+0x19/0x20
[<ffffffff814a23d9>] cpuidle_idle_call+0xa9/0x240
[<ffffffff8101c4bf>] cpu_idle+0xaf/0x120
[<ffffffff815cda8e>] rest_init+0x72/0x74
[<ffffffff81cf4c1a>] start_kernel+0x3b7/0x3c4
[<ffffffff81cf4662>] ? repair_env_string+0x5e/0x5e
[<ffffffff81cf4346>] x86_64_start_reservations+0x131/0x135
[<ffffffff81cf444a>] x86_64_start_kernel+0x100/0x10f
Making sure bf is cleared to NULL in this case restores the
old behaviour.
Signed-off-by: Tom Hughes <tom@compton.nu>
---
drivers/net/wireless/ath/ath9k/recv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 05185fc..6a7dd26 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -658,9 +658,9 @@ static bool ath_edma_get_buffers(struct ath_softc *sc,
__skb_unlink(skb, &rx_edma->rx_fifo);
list_add_tail(&bf->list, &sc->rx.rxbuf);
ath_rx_edma_buf_link(sc, qtype);
- } else {
- bf = NULL;
}
+
+ bf = NULL;
}
*dest = bf;
--
1.7.10.2
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [ath9k-devel] [PATCH] ath9k: fix panic caused by returning a descriptor we have queued for reuse
@ 2012-06-27 17:21 ` Tom Hughes
0 siblings, 0 replies; 6+ messages in thread
From: Tom Hughes @ 2012-06-27 17:21 UTC (permalink / raw)
To: ath9k-devel
Commit 3a2923e83c introduced a bug when a corrupt descriptor
is encountered - although the following descriptor is discarded
and returned to the queue for reuse the associated frame is
also returned for processing. This leads to a panic:
BUG: unable to handle kernel NULL pointer dereference at 000000000000003a
IP: [<ffffffffa02599a5>] ath_rx_tasklet+0x165/0x1b00 [ath9k]
Call Trace:
<IRQ>
[<ffffffff812d7fa0>] ? map_single+0x60/0x60
[<ffffffffa028f044>] ? ath9k_ioread32+0x34/0x90 [ath9k]
[<ffffffffa0292eec>] athk9k_tasklet+0xdc/0x160 [ath9k]
[<ffffffff8105e133>] tasklet_action+0x63/0xd0
[<ffffffff8105dbc0>] __do_softirq+0xc0/0x1e0
[<ffffffff8101a873>] ? native_sched_clock+0x13/0x80
[<ffffffff815f9d5c>] call_softirq+0x1c/0x30
[<ffffffff810151f5>] do_softirq+0x75/0xb0
[<ffffffff8105df95>] irq_exit+0xb5/0xc0
[<ffffffff815fa5b3>] do_IRQ+0x63/0xe0
[<ffffffff815f0cea>] common_interrupt+0x6a/0x6a
<EOI>
[<ffffffff8131840a>] ? intel_idle+0xea/0x150
[<ffffffff813183eb>] ? intel_idle+0xcb/0x150
[<ffffffff814a1db9>] cpuidle_enter+0x19/0x20
[<ffffffff814a23d9>] cpuidle_idle_call+0xa9/0x240
[<ffffffff8101c4bf>] cpu_idle+0xaf/0x120
[<ffffffff815cda8e>] rest_init+0x72/0x74
[<ffffffff81cf4c1a>] start_kernel+0x3b7/0x3c4
[<ffffffff81cf4662>] ? repair_env_string+0x5e/0x5e
[<ffffffff81cf4346>] x86_64_start_reservations+0x131/0x135
[<ffffffff81cf444a>] x86_64_start_kernel+0x100/0x10f
Making sure bf is cleared to NULL in this case restores the
old behaviour.
Signed-off-by: Tom Hughes <tom@compton.nu>
---
drivers/net/wireless/ath/ath9k/recv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 05185fc..6a7dd26 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -658,9 +658,9 @@ static bool ath_edma_get_buffers(struct ath_softc *sc,
__skb_unlink(skb, &rx_edma->rx_fifo);
list_add_tail(&bf->list, &sc->rx.rxbuf);
ath_rx_edma_buf_link(sc, qtype);
- } else {
- bf = NULL;
}
+
+ bf = NULL;
}
*dest = bf;
--
1.7.10.2
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] ath9k: fix panic caused by returning a descriptor we have queued for reuse
2012-06-27 17:21 ` [ath9k-devel] " Tom Hughes
@ 2012-06-27 21:22 ` Felix Fietkau
-1 siblings, 0 replies; 6+ messages in thread
From: Felix Fietkau @ 2012-06-27 21:22 UTC (permalink / raw)
To: Tom Hughes
Cc: linville, linux-wireless, ath9k-devel, mcgrof, jouni, vthiagar, senthilb
On 2012-06-27 7:21 PM, Tom Hughes wrote:
> Commit 3a2923e83c introduced a bug when a corrupt descriptor
> is encountered - although the following descriptor is discarded
> and returned to the queue for reuse the associated frame is
> also returned for processing. This leads to a panic:
>
> BUG: unable to handle kernel NULL pointer dereference at 000000000000003a
> IP: [<ffffffffa02599a5>] ath_rx_tasklet+0x165/0x1b00 [ath9k]
> Call Trace:
> <IRQ>
> [<ffffffff812d7fa0>] ? map_single+0x60/0x60
> [<ffffffffa028f044>] ? ath9k_ioread32+0x34/0x90 [ath9k]
> [<ffffffffa0292eec>] athk9k_tasklet+0xdc/0x160 [ath9k]
> [<ffffffff8105e133>] tasklet_action+0x63/0xd0
> [<ffffffff8105dbc0>] __do_softirq+0xc0/0x1e0
> [<ffffffff8101a873>] ? native_sched_clock+0x13/0x80
> [<ffffffff815f9d5c>] call_softirq+0x1c/0x30
> [<ffffffff810151f5>] do_softirq+0x75/0xb0
> [<ffffffff8105df95>] irq_exit+0xb5/0xc0
> [<ffffffff815fa5b3>] do_IRQ+0x63/0xe0
> [<ffffffff815f0cea>] common_interrupt+0x6a/0x6a
> <EOI>
> [<ffffffff8131840a>] ? intel_idle+0xea/0x150
> [<ffffffff813183eb>] ? intel_idle+0xcb/0x150
> [<ffffffff814a1db9>] cpuidle_enter+0x19/0x20
> [<ffffffff814a23d9>] cpuidle_idle_call+0xa9/0x240
> [<ffffffff8101c4bf>] cpu_idle+0xaf/0x120
> [<ffffffff815cda8e>] rest_init+0x72/0x74
> [<ffffffff81cf4c1a>] start_kernel+0x3b7/0x3c4
> [<ffffffff81cf4662>] ? repair_env_string+0x5e/0x5e
> [<ffffffff81cf4346>] x86_64_start_reservations+0x131/0x135
> [<ffffffff81cf444a>] x86_64_start_kernel+0x100/0x10f
>
> Making sure bf is cleared to NULL in this case restores the
> old behaviour.
>
> Signed-off-by: Tom Hughes <tom@compton.nu>
Acked-by: Felix Fietkau <nbd@openwrt.org>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] [PATCH] ath9k: fix panic caused by returning a descriptor we have queued for reuse
@ 2012-06-27 21:22 ` Felix Fietkau
0 siblings, 0 replies; 6+ messages in thread
From: Felix Fietkau @ 2012-06-27 21:22 UTC (permalink / raw)
To: ath9k-devel
On 2012-06-27 7:21 PM, Tom Hughes wrote:
> Commit 3a2923e83c introduced a bug when a corrupt descriptor
> is encountered - although the following descriptor is discarded
> and returned to the queue for reuse the associated frame is
> also returned for processing. This leads to a panic:
>
> BUG: unable to handle kernel NULL pointer dereference at 000000000000003a
> IP: [<ffffffffa02599a5>] ath_rx_tasklet+0x165/0x1b00 [ath9k]
> Call Trace:
> <IRQ>
> [<ffffffff812d7fa0>] ? map_single+0x60/0x60
> [<ffffffffa028f044>] ? ath9k_ioread32+0x34/0x90 [ath9k]
> [<ffffffffa0292eec>] athk9k_tasklet+0xdc/0x160 [ath9k]
> [<ffffffff8105e133>] tasklet_action+0x63/0xd0
> [<ffffffff8105dbc0>] __do_softirq+0xc0/0x1e0
> [<ffffffff8101a873>] ? native_sched_clock+0x13/0x80
> [<ffffffff815f9d5c>] call_softirq+0x1c/0x30
> [<ffffffff810151f5>] do_softirq+0x75/0xb0
> [<ffffffff8105df95>] irq_exit+0xb5/0xc0
> [<ffffffff815fa5b3>] do_IRQ+0x63/0xe0
> [<ffffffff815f0cea>] common_interrupt+0x6a/0x6a
> <EOI>
> [<ffffffff8131840a>] ? intel_idle+0xea/0x150
> [<ffffffff813183eb>] ? intel_idle+0xcb/0x150
> [<ffffffff814a1db9>] cpuidle_enter+0x19/0x20
> [<ffffffff814a23d9>] cpuidle_idle_call+0xa9/0x240
> [<ffffffff8101c4bf>] cpu_idle+0xaf/0x120
> [<ffffffff815cda8e>] rest_init+0x72/0x74
> [<ffffffff81cf4c1a>] start_kernel+0x3b7/0x3c4
> [<ffffffff81cf4662>] ? repair_env_string+0x5e/0x5e
> [<ffffffff81cf4346>] x86_64_start_reservations+0x131/0x135
> [<ffffffff81cf444a>] x86_64_start_kernel+0x100/0x10f
>
> Making sure bf is cleared to NULL in this case restores the
> old behaviour.
>
> Signed-off-by: Tom Hughes <tom@compton.nu>
Acked-by: Felix Fietkau <nbd@openwrt.org>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] ath9k: fix panic caused by returning a descriptor we have queued for reuse
2012-06-27 17:21 ` [ath9k-devel] " Tom Hughes
@ 2012-06-28 1:09 ` Sujith Manoharan
-1 siblings, 0 replies; 6+ messages in thread
From: Sujith Manoharan @ 2012-06-28 1:09 UTC (permalink / raw)
To: linville
Cc: Tom Hughes, linux-wireless, ath9k-devel, rodrigue, jouni,
vthiagar, senthilb
Tom Hughes wrote:
> Commit 3a2923e83c introduced a bug when a corrupt descriptor
> is encountered - although the following descriptor is discarded
> and returned to the queue for reuse the associated frame is
> also returned for processing. This leads to a panic:
>
> BUG: unable to handle kernel NULL pointer dereference at 000000000000003a
John, can you queue this regression fix for 3.5 ? And the patch that fixes a
WEP regression is required too (bed3d9c0b71f9afbfec905cb6db3b9f16be29d4d).
thanks,
Sujith
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] [PATCH] ath9k: fix panic caused by returning a descriptor we have queued for reuse
@ 2012-06-28 1:09 ` Sujith Manoharan
0 siblings, 0 replies; 6+ messages in thread
From: Sujith Manoharan @ 2012-06-28 1:09 UTC (permalink / raw)
To: ath9k-devel
Tom Hughes wrote:
> Commit 3a2923e83c introduced a bug when a corrupt descriptor
> is encountered - although the following descriptor is discarded
> and returned to the queue for reuse the associated frame is
> also returned for processing. This leads to a panic:
>
> BUG: unable to handle kernel NULL pointer dereference at 000000000000003a
John, can you queue this regression fix for 3.5 ? And the patch that fixes a
WEP regression is required too (bed3d9c0b71f9afbfec905cb6db3b9f16be29d4d).
thanks,
Sujith
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-06-28 1:10 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-27 17:21 [PATCH] ath9k: fix panic caused by returning a descriptor we have queued for reuse Tom Hughes
2012-06-27 17:21 ` [ath9k-devel] " Tom Hughes
2012-06-27 21:22 ` Felix Fietkau
2012-06-27 21:22 ` [ath9k-devel] " Felix Fietkau
2012-06-28 1:09 ` Sujith Manoharan
2012-06-28 1:09 ` [ath9k-devel] " Sujith Manoharan
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.