One-off regression fix for 6.3 [was: Re: [PATCH] wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels()]

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Toke Høiland-Jørgensen <toke@toke.dk> writes:

> This partially reverts commit e161d4b60ae3a5356e07202e0bfedb5fad82c6aa.
>
> Turns out the channelmap variable is not actually read-only, it's modified
> through the MCI_GPM_CLR_CHANNEL_BIT() macro further down in the function,
> so making it read-only causes page faults when that code is hit.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217183
> Fixes: e161d4b60ae3 ("wifi: ath9k: Make arrays prof_prio and channelmap static const")
> Cc: stable@vger.kernel.org
> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>

Hi Linus

Thorsten already pulled you into the thread further down, but I figured
I'd do this writeup anyway so you have the full context:

The patch quoted above[0] fixes a regression in the ath9k driver that was
introduced in 6.2, which causes a kernel BUG() whenever the "Bluetooth
co-existence" feature in the driver is enabled (which seems to be the
default on at least some systems).

Because of unfortunate timing (caused by an impedance mismatch between
the wireless tree and the -net tree, and my failure to realise this and
push it directly to -net), this patch did not make it into this week's
network tree pull request to you. Which means that unless you decide to
do an -rc8, this regression will also be in the 6.3 release, and it may
take several more weeks before the fix makes it into a stable release.

So, with a bit of prodding from Thorsten, I'm writing this to ask you if
you'd be willing to pull this patch directly from the mailing list as a
one-off? It's a fairly small patch, and since it's a (partial) revert
the risk of it being the cause of new regressions should be fairly
small. One of the reporters on the Bugzilla (linked above) confirmed
that the patch does indeed fix the regression.

In case you *don't* want to take this patch directly, Jakub has agreed
to pull it directly into -net, in which case it'll land in your tree via
the next networking pull request. Either way, as indicated by the
sibling thread Thorsten Cc'ed you on, we'll take your opinion on the
best way to handle this into account in the future. Just let us know :)

Thanks,
-Toke


[0] Direct Lore link: https://lore.kernel.org/r/20230413214118.153781-1-toke@toke.dk