From: Johannes Berg <johannes@sipsolutions.net>
To: Jeff Johnson <jeff.johnson@oss.qualcomm.com>,
linux-wireless@vger.kernel.org
Cc: "ath12k@lists.infradead.org" <ath12k@lists.infradead.org>
Subject: Re: [RFC PATCH 00/12] wifi: AP side locking improvements
Date: Tue, 06 Oct 2026 09:14:59 +0200 [thread overview]
Message-ID: <623f20912fee5ed614e3a884f54c116bb8f2944c.camel@sipsolutions.net> (raw)
In-Reply-To: <3db68884-f6b5-499c-9959-7eec59ba40cd@oss.qualcomm.com>
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, 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.
> Pre-existing but Newly Exposed: ath12k_regd_update vs ath12k_reg_notifier on
> ah->regd_updated
>
> ath12k_regd_update() is called from ath12k_regd_update_work (a workqueue) and
> reads then writes ah->regd_updated with no lock at all. ath12k_reg_notifier()
> writes ah->regd_updated = false also with no lock. These two were already
> concurrent before the series — workqueue items are not serialized by RTNL — so
> this is not a new problem introduced by the patches. However, RTNL previously
> prevented the reg notifier from being called while a mac op was running,
> which reduced the window. That window is now wider.
I don't think it's correct about that widening very much, "RTNL ...
prevented ... while a mac op was running" isn't true for most
operations, only start/stop (roughly), and e.g. sta_state changes the
state here.
But you'll need to fix that locally in the driver anyway.
I'm working also on adding clang context analysis to all of this, but
I've only _just_ (yesterday) worked out our internal build systems to
have clang 23 to be able to actually validate it, and will obviously
need to redo the (very small) adjustments in cfg80211 on top of this
series. Then we can annotate such things with clang and the right lock.
johannes
next prev parent reply other threads:[~2026-10-06 7:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-04 21:40 [RFC PATCH 00/12] wifi: AP side locking improvements Johannes Berg
2026-10-04 21:40 ` [RFC PATCH 01/12] wifi: mac80211: protect AP template pointers with a spinlock Johannes Berg
2026-10-04 21:40 ` [RFC PATCH 02/12] wifi: nl80211: add NL80211_CMD_UPDATE_BEACON Johannes Berg
2026-10-04 21:40 ` [RFC PATCH 03/12] wifi: mac80211: implement lockless beacon updates Johannes Berg
2026-10-09 16:05 ` Johannes Berg
2026-10-04 21:40 ` [RFC PATCH 04/12] wifi: mac80211_hwsim: support " Johannes Berg
2026-10-04 21:40 ` [RFC PATCH 05/12] wifi: cfg80211: make cookie counter atomic Johannes Berg
2026-10-04 21:40 ` [RFC PATCH 06/12] wifi: nl80211: allow mgmt frame TX without wiphy mutex Johannes Berg
2026-10-04 21:40 ` [RFC PATCH 07/12] wifi: mac80211: refactor mgmt frames TX Johannes Berg
2026-10-04 21:40 ` [RFC PATCH 08/12] wifi: mac80211: implement mgmt_tx_unlocked() Johannes Berg
2026-10-04 21:40 ` [RFC PATCH 09/12] wifi: mac80211: don't require wiphy mutex for probe_peer Johannes Berg
2026-10-04 21:40 ` [RFC PATCH 10/12] wifi: nl80211: probe peers without wiphy mutex Johannes Berg
2026-10-04 21:40 ` [RFC PATCH 11/12] wifi: mac80211: don't require wiphy mutex for control port TX Johannes Berg
2026-10-04 21:40 ` [RFC PATCH 12/12] wifi: nl80211: transmit control port frames without wiphy mutex Johannes Berg
2026-10-05 8:43 ` [RFC PATCH 00/12] wifi: AP side locking improvements Johannes Berg
2026-10-06 2:05 ` Jeff Johnson
2026-10-06 7:14 ` Johannes Berg [this message]
2026-10-06 7:55 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=623f20912fee5ed614e3a884f54c116bb8f2944c.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=ath12k@lists.infradead.org \
--cc=jeff.johnson@oss.qualcomm.com \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox