[PATCH ath-current] wifi: ath11k: fix locking problem in ath11k_dp_rx_tid_del_func()

Jeff Johnson jeff.johnson at oss.qualcomm.com
Fri Jul 31 09:31:40 PDT 2026


On 7/31/2026 7:36 AM, Nicolas Escande wrote:
> On Fri Jul 31, 2026 at 8:49 AM CEST, Baochen Qiang wrote:
>> On 7/29/2026 4:57 PM, Nicolas Escande wrote:
>>
>> while this seems the minimal fix which stable team might prefer, how about refactoring as
>> firstly detaching all the expired entries onto a local list under the lock and flushing
>> that list afterwards:
>>
>>   LIST_HEAD(flush_list);
>>
>>   spin_lock_bh(&dp->reo_cmd_lock);
>>   list_for_each_entry_safe(elem, tmp, &dp->reo_cmd_cache_flush_list, list) {
>>         if () {
>>                 list_move_tail(&elem->list, &flush_list);
>>         }
>>   }
>>   spin_unlock_bh(&dp->reo_cmd_lock);
>>
>>   list_for_each_entry_safe(elem, tmp, &flush_list, list) {
>>         list_del(&elem->list);
>>         ath11k_dp_reo_cache_flush(ab, &elem->data);
>>         kfree(elem);
>>   }
>>
>> This fully decouples the concurrency from the flushing: the detach phase runs entirely
>> under the lock, and the flush phase walks a thread-private list where no concurrency
>> exists. It's a single O(N) pass instead of the O(N^2) worst case of re-scanning from the
>> head, and it avoids bouncing reo_cmd_lock once per freed entry.
>>
>> Also this seems simpler and more direct — its correctness is obvious by construction;
>> while the fix of this patch is less self-evident: a reader may not easily grasp why the
>> code has to rescan from the head after re-taking the lock.
>>
>> Non-blocking though — either form fixes the crash. If you'd rather keep the minimal goto
>> retry for the stable backport and do the detach-list version as a follow-up cleanup, that
>> works for me too.
> 
> Yes I remember that we fixed it this way with Maxime to minimize code change.
> But doing it your way seems to be the better thing to do. So I agree I'll
> rework this wit the single iteration under lock + cleanup pass.
> But it will take me some time to do so, I do not have much time right now. 
> So if Jeff prefers taking this one as is just to have a quick fix no objection
> either, I'll rework it later for next. You guys tell me what you prefer.

Let's rework to use the local list. We have that pattern elsewhere as well.

/jeff





More information about the ath11k mailing list