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:45:15 +0200 [thread overview]
Message-ID: <f1669b69-6762-1341-8822-de08d9ddd55b@gmail.com> (raw)
In-Reply-To: <fd43b218-7dc7-22dd-664b-46c55c3dd94e@gmail.com>
On 10/9/19 9:23 PM, Erik Stromdahl wrote:
>
>
> 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.
>
I found this backtrace in a log file:
(it does not show the call to ieee80211_tx_dequeue_ni(), but it shows that
ath10k_sdio_irq_handler() is called from process context)
irq/62-mmc1-65 [000] .... 785.261081: ath10k_mac_op_wake_tx_queue <-ieee80211_queue_skb
irq/62-mmc1-65 [000] .... 785.261090: <stack trace>
=> ieee80211_queue_skb
=> __ieee80211_subif_start_xmit
=> ieee80211_subif_start_xmit
=> dev_hard_start_xmit
=> __dev_queue_xmit
=> dev_queue_xmit
=> ip_finish_output2
=> ip_finish_output
=> ip_output
=> ip_local_out
=> ip_queue_xmit
=> tcp_transmit_skb
=> tcp_write_xmit
=> __tcp_push_pending_frames
=> tcp_rcv_established
=> tcp_v4_do_rcv
=> tcp_v4_rcv
=> ip_local_deliver_finish
=> ip_local_deliver
=> ip_rcv_finish
=> ip_rcv
=> __netif_receive_skb_core
=> __netif_receive_skb
=> netif_receive_skb_internal
=> netif_receive_skb
=> ieee80211_deliver_skb
=> ieee80211_rx_handlers
=> ieee80211_prepare_and_rx_handle
=> ieee80211_rx_napi
=> ath10k_htt_t2h_msg_handler
=> ath10k_htt_htc_t2h_msg_handler
=> ath10k_sdio_mbox_rxmsg_pending_handler
=> ath10k_sdio_irq_handler <- ath10k_mac_tx_push_pending() is called from here
=> process_sdio_pending_irqs
=> sdio_run_irqs
=> sdhci_thread_irq
=> irq_thread_fn
=> irq_thread
=> kthread
=> ret_from_fork
=> 0
From ath10k_sdio_irq_handler(), the call chain down to ieee80211_tx_dequeue_ni()
looks like this:
ath10k_sdio_irq_handler() =>
ath10k_mac_tx_push_pending() =>
ath10k_mac_schedule_txq() =>
ath10k_mac_tx_push_txq() =>
ieee80211_tx_dequeue_ni()
>
>> 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.
>>
prev parent reply other threads:[~2019-10-09 19:45 UTC|newest]
Thread overview: 7+ 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 ` [PATCH 2/2] ath10k: switch to ieee80211_tx_dequeue_ni Erik Stromdahl
2019-10-01 11:16 ` Kalle Valo
2019-10-01 11:48 ` Kalle Valo
2019-10-01 17:13 ` Peter Oh
2019-10-09 19:23 ` Erik Stromdahl
2019-10-09 19:45 ` Erik Stromdahl [this message]
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=f1669b69-6762-1341-8822-de08d9ddd55b@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).