Kalle Valo <kvalo@xxxxxxxxxx> writes: > (dropping stable from cc) > > Toke Høiland-Jørgensen <toke@xxxxxxx> writes: > >> Kalle Valo <kvalo@xxxxxxxxxx> writes: >> >>> 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> >>> >>> I guess the casting in MCI_GPM_CLR_CHANNEL_BIT() hide this and made it >>> impossible for the compiler to detect it? A perfect example why I hate >>> casting :) >> >> Yup, exactly. I was also assuming the compiler would catch it, but yay, C! :/ > > We have so many static checkers that I wonder if those would be able to > catch these kind of buggy casts? We had a similar bug in rtw89 something > like a year ago. No idea. Would be nice, yeah... :) >> Anyway, cf the bugzilla this was a pretty bad regression for 6.2, so >> would be good to move this along reasonably quickly (although I guess we >> just missed the -net PR for rc7)... > > I'm not planning to send anymore stuff to v6.3 so my plan is to take > this to -next. The merge window is very close anyway so this shouldn't > cause too much delay. Hmm, okay, a bit unfortunate that we'll ship 6.3 with the same bug, but if it goes in during the merge window, I guess we'll get the fix into 6.3.1 (or something close to that) via stable? I can live with that... -Toke
