Re: [PATCH] wifi: cfg80211: publish PMSR request before starting the driver

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2026-07-23 at 09:09 +0800, Zhao Li wrote:
> 
> This ordering also permits a successful driver callback to complete the
> request synchronously. Document the resulting start_pmsr lifetime contract.

From a locking perspective perhaps yes, but cfg80211_pmsr_complete()
sends the results to userspace immediately, so userspace might see a
completion with a cookie before it even got the cookie as the request
response, which (semantically) makes no sense.

Given that measurement requests are always going to take some time, I
don't think this is an issue in practice that we really need to work
hard to prevent (we'd have to do something like attaching the result to
the request on the list, pivot to a wiphy locked worker, etc.)

However, I don't think it makes sense to actually *document* that it's
now possible - it's only possible from the kernel's locking POV, from
userspace's POV it's still highly confusing at best, and it makes no
sense semantically either.

At best the documentation would be something like "the kernel doesn't
crash if the request is completed before returning success" but that's
not useful either :)

> +	/*
> +	 * Publish before the driver can complete the request. Completion may free
> +	 * it before rdev_start_pmsr() returns, so use the cookie snapshot below.
> +	 */

That comment then should call out how it's really about preventing races
with drivers from doing UAF (we could technically be preempted here
too), rather than making that sound like a reasonable order - just
saying "Under races and/or broken drivers immediate completion might
free it ..." or something along those lines would be better I think.

johannes