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()]

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 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

Re: 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()]

[Linus Torvalds]

On Thu, Apr 20, 2023 at 2:09 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> 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.

Sure. I'm always open to direct fixes when there is no controversy
about the fix. No problem. I still happily deal with individual
patches.

And yes, I do consider "regression in an earlier release" to be a
regression that needs fixing.

There's obviously a time limit: if that "regression in an earlier
release" was a year or more ago, and just took forever for people to
notice, and it had semantic changes that now mean that fixing the
regression could cause a _new_ regression, then that can cause me to
go "Oh, now the new semantics are what we have to live with".

But something like this, where the regression was in the previous
release and it's just a clear fix with no semantic subtlety, I
consider to be just a regular regression that should be expedited -
partly to make it into stable, and partly to avoid having to put the
fix into _another_ stable kernel..

             Linus

Re: 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]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Thu, Apr 20, 2023 at 2:09 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>
>> 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.
>
> Sure. I'm always open to direct fixes when there is no controversy
> about the fix. No problem. I still happily deal with individual
> patches.

Awesome, thanks!

> And yes, I do consider "regression in an earlier release" to be a
> regression that needs fixing.
>
> There's obviously a time limit: if that "regression in an earlier
> release" was a year or more ago, and just took forever for people to
> notice, and it had semantic changes that now mean that fixing the
> regression could cause a _new_ regression, then that can cause me to
> go "Oh, now the new semantics are what we have to live with".
>
> But something like this, where the regression was in the previous
> release and it's just a clear fix with no semantic subtlety, I
> consider to be just a regular regression that should be expedited -
> partly to make it into stable, and partly to avoid having to put the
> fix into _another_ stable kernel..

OK, duly noted; thank you for clarifying :)

-Toke