From: Erik Stromdahl <erik.stromdahl@gmail.com> To: Peter Oh <peter.oh@eero.com>, Kalle Valo <kvalo@codeaurora.org> Cc: johannes@sipsolutions.net, davem@davemloft.net, linux-wireless@vger.kernel.org, ath10k@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] ath10k: switch to ieee80211_tx_dequeue_ni Date: Wed, 9 Oct 2019 21:23:31 +0200 [thread overview] Message-ID: <fd43b218-7dc7-22dd-664b-46c55c3dd94e@gmail.com> (raw) In-Reply-To: <19f8023a-1943-9bf5-9a59-a7643f7692bf@eero.com> 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. >
WARNING: multiple messages have this Message-ID (diff)
From: Erik Stromdahl <erik.stromdahl@gmail.com> To: Peter Oh <peter.oh@eero.com>, Kalle Valo <kvalo@codeaurora.org> Cc: johannes@sipsolutions.net, linux-wireless@vger.kernel.org, davem@davemloft.net, ath10k@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] ath10k: switch to ieee80211_tx_dequeue_ni Date: Wed, 9 Oct 2019 21:23:31 +0200 [thread overview] Message-ID: <fd43b218-7dc7-22dd-664b-46c55c3dd94e@gmail.com> (raw) In-Reply-To: <19f8023a-1943-9bf5-9a59-a7643f7692bf@eero.com> 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. > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2019-10-09 19:23 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-17 20:01 [PATCH 1/2] mac80211: add tx dequeue function for process context Erik Stromdahl 2019-06-17 20:01 ` Erik Stromdahl 2019-06-17 20:01 ` [PATCH 2/2] ath10k: switch to ieee80211_tx_dequeue_ni Erik Stromdahl 2019-06-17 20:01 ` Erik Stromdahl 2019-10-01 11:16 ` Kalle Valo 2019-10-01 11:16 ` Kalle Valo 2019-10-01 11:48 ` Kalle Valo 2019-10-01 11:48 ` Kalle Valo 2019-10-01 17:13 ` Peter Oh 2019-10-01 17:13 ` Peter Oh 2019-10-09 19:23 ` Erik Stromdahl [this message] 2019-10-09 19:23 ` Erik Stromdahl 2019-10-09 19:45 ` Erik Stromdahl 2019-10-09 19:45 ` Erik Stromdahl
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=fd43b218-7dc7-22dd-664b-46c55c3dd94e@gmail.com \ --to=erik.stromdahl@gmail.com \ --cc=ath10k@lists.infradead.org \ --cc=davem@davemloft.net \ --cc=johannes@sipsolutions.net \ --cc=kvalo@codeaurora.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=peter.oh@eero.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.