[PATCH] ath10k: fix kernel panic while shutting down AP

Kalle Valo kvalo at qca.qualcomm.com
Wed Oct 8 05:37:00 PDT 2014

Michal Kazior <michal.kazior at tieto.com> writes:

>>> Until now we have protected arvif->beacon_buf with data_lock. How do we
>>> know that this is safe to do without taking data_lock?
>> As said, spin_lock can not be used for dma_free_coherent.
>> arvif->beacon_buf is already protected by conf_mutex. At this state
>> in ath10k_halt path, no one can access beacon_buf. So mutex lock itself
>> is sufficient.
> beacon_buf is protected by conf_mutex implicitly. It wasn't the main
> intent. It is protected with data_lock spinlock.
> Do not trust the device - if there's a spurious SWBA event while
> ath10k_remove_interface() is running you could end up with invalid
> memory access.
> It might be acceptable to drop the spinlock for ath10k_halt() since
> the device is guaranteed to be stopped at that point (effectively
> reset) though.
> Anyway I'm hoping this bug can be fixed with the gfp flag.

Yeah, fixing this with the gfp flag would be much better solution.

Kalle Valo

More information about the ath10k mailing list