Re: [PATCH] wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels()

[Kalle Valo <kvalo@kernel.org>]

(dropping stable from cc)

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

> Kalle Valo <kvalo@kernel.org> writes:
>
>> 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>
>>
>> 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.

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

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches