linux-kernel - Re: [PATCH 2/2] ath10k: switch to ieee80211_tx_dequeue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f1669b69-6762-1341-8822-de08d9ddd55b@gmail.com>
Date:   Wed, 9 Oct 2019 21:45:15 +0200
From:   Erik Stromdahl <erik.stromdahl@...il.com>
To:     Peter Oh <peter.oh@...o.com>, Kalle Valo <kvalo@...eaurora.org>
Cc:     johannes@...solutions.net, davem@...emloft.net,
        linux-wireless@...r.kernel.org, ath10k@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] ath10k: switch to ieee80211_tx_dequeue_ni



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@...il.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@...il.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.
>>