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] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 9 Oct 2019 21:23:31 +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/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.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ