[Make-wifi-fast] ath9k airtime fairness stabiity issues?

[Michal Kazior]

On 5 January 2017 at 14:23, Felix Fietkau <nbd at nbd.name> wrote:
> On 2017-01-05 14:22, Loganaden Velvindron wrote:
>> On Thu, Jan 5, 2017 at 4:59 PM, Dave Taht <dave.taht at gmail.com> wrote:
>>> Felix:
>>>
>>> Was there a bugreport?  (don't see one)
>>>
>>> Do you have a specific device or behavior triggering this revert?
>>>
>>>
>>> On Thu, Jan 5, 2017 at 4:42 AM, Dave Taht <dave.taht at gmail.com> wrote:
>>>> https://github.com/lede-project/source/commit/c296ba834db4ce8c71e0ad7030aab188fe60b27b
>>>
>>>
>>
>> Hi nbd & Toke,
>>
>> Would it be possible to enable it only on platforms like the tp-link
>> archer c7 v2 and the ubnt, where we have confirmed test reports for
>> the upcoming release ?
> I think it's quite unlikely that these issues are hardware specific.
> It's probably more related to the environment, types of clients, or even
> traffic patterns.

Some people are complaining ath10k is unstable for them when
wake_tx_queue is enabled. I suspect the ATF problem in ath9k might be
providing extra opportunities to hit the same bug.

I think RCU is not properly handled. txq_info shares lifecycle of
sta_info and should therefore be protected in the same manner. When
you queue up ieee80211_txq in a driver and use it later you
effectively break RCU. Grabbing rcu_read_lock() *later*, e.g. when
re-scheduling tx is not sufficient to protect from the possible race
of part1/part2 of station destroying logic and driver accessing its
internal txq list.

There seems to be a mechanism to hook up with to fix that already -
drv_sta_pre_rcu_remove().

I've been seldom looking at the ath10k problem and noticed this bit. I
didn't get a chance (and probably won't, any time soon) to take a
closer look, nor test/verify it for that matter.


Michał