[RFC] mac80211: Potential sleep in atomic context in __ieee80211_wake_txqs

[RFC] mac80211: Potential sleep in atomic context in __ieee80211_wake_txqs

[Yunseong Kim]

Hi,

I found a potential PREEMPT_RT issue I noticed in __ieee80211_wake_txqs()

 static void __ieee80211_wake_txqs(struct ieee80211_sub_if_data *sdata, int ac)
 {
     ...
     local_bh_disable();
     spin_lock(&fq->lock);
     ...
 }

This sequence of local_bh_disable() followed by spin_lock(). On an 
RT-enabled system, spin_lock() is converted to a sleeping lock. Calling it
immediately after local_bh_disable() creates a situation where a sleeping
function is called from an atomic context, which will lead to a sleep in
atomic context if the lock is contended.

The conventional fix for this pattern is to replace the two lines with a
single, RT-safe call to spin_lock_bh(&fq->lock).

I wanted to bring this up for discussion before preparing a patch. Is this
a valid concern, and would a patch to correct this locking be the right
approach?

Thank you for your time and consideration.


Best regards,
Yunseong Kim

Re: [RFC] mac80211: Potential sleep in atomic context in __ieee80211_wake_txqs

[Sebastian Andrzej Siewior]

On 2025-08-19 01:56:00 [+0900], Yunseong Kim wrote:
> Hi,
Hi,

> I found a potential PREEMPT_RT issue I noticed in __ieee80211_wake_txqs()
> 
>  static void __ieee80211_wake_txqs(struct ieee80211_sub_if_data *sdata, int ac)
>  {
>      ...
>      local_bh_disable();
>      spin_lock(&fq->lock);
>      ...
>  }
> 
> This sequence of local_bh_disable() followed by spin_lock(). On an 

As explained in the previous mail regarding for
inet_twsk_hashdance_schedule(), this is fine.

> Best regards,
> Yunseong Kim

Sebastian