Toke Høiland-Jørgensen <toke@xxxxxxx> 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@xxxxxxxxxxxxxxx > Signed-off-by: Toke Høiland-Jørgensen <toke@xxxxxxx> 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@xxxxxxx
