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

[Kalle Valo <kvalo@qca.qualcomm.com>]

Michal Kazior <michal.kazior@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