linux-kernel - Re: ieee80211_handle_wake_tx_queue and dynamic ps regression

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]

Message-ID: <cf5e9339-2511-1135-71da-a8342b264414@linaro.org>
Date:   Tue, 10 Jan 2023 14:47:24 +0000
From:   Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To:     linux-kernel@...r.kernel.org, alexander@...zel-home.de,
        johannes.berg@...el.com, Kalle Valo <kvalo@...eaurora.org>,
        linux-wireless@...r.kernel.org
Subject: Re: ieee80211_handle_wake_tx_queue and dynamic ps regression

On 10/01/2023 12:44, Bryan O'Donoghue wrote:
> + linux-wireless
> On 10/01/2023 12:35, Bryan O'Donoghue wrote:
>> commit a790cc3a4fad75048295571a350b95b87e022a5a 
>> (wake_tx_queue-broken-23-08-01)
>> Author: Alexander Wetzel <alexander@...zel-home.de>
>> Date:   Sun Oct 9 18:30:39 2022 +0200
>>
>>      wifi: mac80211: add wake_tx_queue callback to drivers
>>
>> is causing a regression with
>>
>> - CONF_PS = 1
>> - CONF_DYNAMIC_PS = 0
>> - ieee80211_handle_wake_tx_queue
>>
>> In this case we get stuck in a loop similar to this
>>
>> // IEEE80211_CONF_CHANGE_PS
>> [   17.255480] wcn36xx: wcn36xx_change_ps/312 enable
>> [   18.088835] ieee80211_tx_h_dynamic_ps/263 setting 
>> IEEE80211_QUEUE_STOP_REASON_PS
>> [   18.088906] ieee80211_handle_wake_tx_queue/334 entry
>> [   18.091505] ieee80211_dynamic_ps_disable_work/2250 calling 
>> ieee80211_hw_config()
>> [   18.095370] ieee80211_handle_wake_tx_queue/338 wake_tx_push_queue
>>
>> // IEEE80211_CONF_CHANGE_PS
>> [   18.102625] wcn36xx: wcn36xx_change_ps/312 disable
>> [   18.107643] wake_tx_push_queue/303 entry
>>
>> // txq is stopped here reason == IEEE80211_QUEUE_STOP_REASON_PS
>> [   18.107654] wake_tx_push_queue/311 q_stopped bitmask 0x00000002 
>> IEEE80211_QUEUE_STOP_REASON_PS true
>> [   18.107661] wake_tx_push_queue/324 exit
>> [   18.107667] ieee80211_handle_wake_tx_queue/342 exit
>> [   18.115560] ieee80211_handle_wake_tx_queue/334 entry
>> [   18.139937] ieee80211_handle_wake_tx_queue/338 wake_tx_push_queue
>> [   18.145163] wake_tx_push_queue/303 entry
>> [   18.150016] ieee80211_dynamic_ps_disable_work/2252 completed 
>> ieee80211_hw_config()
>>
>> // now we unset IEEE80211_QUEUE_STOP_REASON_PS but too late
>> [   18.151145] wake_tx_push_queue/311 q_stopped bitmask 0x00000002 
>> IEEE80211_QUEUE_STOP_REASON_PS true
>> [   18.155263] ieee80211_dynamic_ps_disable_work/2254 clearing 
>> IEEE80211_QUEUE_STOP_REASON_PS
>> [   18.162531] wake_tx_push_queue/324 exit
>> [   18.162548] ieee80211_handle_wake_tx_queue/342 exit
>> [   18.183639] ieee80211_dynamic_ps_disable_work/2259 cleared 
>> IEEE80211_QUEUE_STOP_REASON_PS
>>
>> // IEEE80211_CONF_CHANGE_PS runs again
>> [   18.215487] wcn36xx: wcn36xx_change_ps/312 enable
>>
>> We get stuck in that loop. Packets getting transmitted is a rare 
>> event, most are dropped.

BTW I considered implementing a wcn36xx specific wake_tx callback - 
which maybe should be done anyway.

I _don't_ see other drivers checking for q_stopped & 
IEEE80211_QUEUE_STOP_REASON_PS

Should they be ?

If they should check IEEE80211_QUEUE_STOP_REASON_PS, then right now, 
they don't. If they shouldn't check IEEE80211_QUEUE_STOP_REASON_PS then 
neither should the generic replacement ieee80211_handle_wake_tx_queue()

---
bod