Re: [PATCH 2/2] ath10k: switch to ieee80211_tx_dequeue_ni

[Erik Stromdahl]

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