Messages in this thread | | | Subject | Re: [PATCH 2/2] ath10k: switch to ieee80211_tx_dequeue_ni | From | Erik Stromdahl <> | Date | Wed, 9 Oct 2019 21:23:31 +0200 |
| |
On 10/1/19 7:13 PM, Peter Oh wrote: > > On 10/1/19 4:48 AM, Kalle Valo wrote: >> Erik Stromdahl <erik.stromdahl@gmail.com> writes: >> >>> Since ath10k_mac_tx_push_txq() can be called from process context, we >>> must explicitly disable softirqs before the call into mac80211. >>> >>> By calling ieee80211_tx_dequeue_ni() instead of ieee80211_tx_dequeue() >>> we make sure softirqs are always disabled even in the case when >>> ath10k_mac_tx_push_txq() is called from process context. >>> >>> Calling ieee80211_tx_dequeue_ni() with softirq's already disabled >>> (e.g., from softirq context) should be safe as the local_bh_disable() >>> and local_bh_enable() functions (called from ieee80211_tx_dequeue_ni) >>> are fully reentrant. >>> >>> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com> >> I already applied this, but I still want to check _why_ you are changing >> this? Is it that you want to call ath10k_mac_tx_push_pending() from a >> workqueue in sdio.c in a future patch, or what? Because at the moment me >> and Johannes were not able to find where this is called in process >> context. >> SDIO irqs are threaded irqs (at least on my iMX6 board) and hence process context. I will see if I can find a trace that shows the call chain more exactly.
> It seems Johannes wants to fix it in mac80211. > > [PATCH v2] mac80211: keep BHs disabled while calling drv_tx_wake_queue() > > Drivers typically expect this, as it's the case for almost all cases > where this is called (i.e. from the TX path). Also, the code in mac80211 > itself (if the driver calls ieee80211_tx_dequeue()) expects this as it > uses this_cpu_ptr() without additional protection. >
| |