This is called with spinlocks held so we have to use GFP_ATOMIC. It's
the sc_pcu_lock in ath9k_stop() that's the issue. The call tree looks
like this:
ath9k_stop()
ath_prepare_reset()
ath_stoprecv()
ath_flushrecv()
ath_rx_tasklet()
ath9k_dfs_process_phyerr()
pd->add_pulse() => dpd_add_pulse()
channel_detector_get()
channel_detector_create()
pri_detector_init()
channel_detector_create() uses GFP_ATOMIC as well.
Signed-off-by: Dan Carpenter <[email protected]>
---
Static analysis stuff. I haven't tested this but it looks like a real
bug to me.
diff --git a/drivers/net/wireless/ath/ath9k/dfs_pri_detector.c b/drivers/net/wireless/ath/ath9k/dfs_pri_detector.c
index 5e48c55..e056c73 100644
--- a/drivers/net/wireless/ath/ath9k/dfs_pri_detector.c
+++ b/drivers/net/wireless/ath/ath9k/dfs_pri_detector.c
@@ -434,7 +434,8 @@ struct pri_detector *
pri_detector_init(const struct radar_detector_specs *rs)
{
struct pri_detector *de;
- de = kzalloc(sizeof(*de), GFP_KERNEL);
+
+ de = kzalloc(sizeof(*de), GFP_ATOMIC);
if (de == NULL)
return NULL;
de->exit = pri_detector_exit;
On 04/16/2013 09:51 AM, Dan Carpenter wrote:
> This is called with spinlocks held so we have to use GFP_ATOMIC. It's
> the sc_pcu_lock in ath9k_stop() that's the issue. The call tree looks
> like this:
>
> ath9k_stop()
> ath_prepare_reset()
> ath_stoprecv()
> ath_flushrecv()
> ath_rx_tasklet()
> ath9k_dfs_process_phyerr()
> pd->add_pulse() => dpd_add_pulse()
> channel_detector_get()
> channel_detector_create()
> pri_detector_init()
>
> channel_detector_create() uses GFP_ATOMIC as well.
>
> Signed-off-by: Dan Carpenter <[email protected]>
> ---
> Static analysis stuff. I haven't tested this but it looks like a real
> bug to me.
>
Thanks Dan,
it is a bug that slipped through the related patch in [1].
Tested-by & Acked-by: Zefir Kurtisi <[email protected]>
[1] http://article.gmane.org/gmane.linux.kernel.wireless.general/106349/