Re: [RFC PATCH 00/12] wifi: AP side locking improvements

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2026-10-06 at 09:14 +0200, Johannes Berg wrote:
> On Mon, 2026-10-05 at 19:05 -0700, Jeff Johnson wrote:
> > With both the redux and this series applied, I prompted my review agent:
> > prior to the 2 patchsets (18 patches and 12 patches) ath12k relied upon the
> > wiphy mutex to serialize many of the mac80211 operations. are any ath12k
> > object references now subject to new race conditions with this entire set of
> > 30 patches applied?
> 
> :)
> 
> > The reply:
> > <LLM>
> > New Race: ath12k_reg_notifier vs ath12k_mac_op_start/ath12k_mac_op_stop on
> > ah->state
> 
> That's a fair point,

Actually, I think it was wrong: ah->state is only used within the
NL80211_REGDOM_SET_BY_DRIVER block, which is already only called in
reg_process_self_managed_hint(), which already holds wiphy mutex. It
might be correct about ah->regd_updated in this case, but then it found
that was _already_ racy.

> but easy to resolve - we can just lock the wiphy in
> the loop of notify_self_managed_wiphys(). It already can't go away since
> we have cfg80211_mutex. Looking slightly deeper, we should guarantee
> that we hold the wiphy mutex for a bunch of these operations to the
> driver, and that needs more than a single line of code, but looks
> totally doable.

That's probably still desired so we have _any_ locking, but needs to
drop the wiphy mutex in ath12k and rtw89.

johannes