Michal Kazior <michal.kazior@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
