Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Kalle Valo <kvalo@kernel.org>
To:     Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
Cc:     Colin Ian King <colin.i.king@gmail.com>,
        linux-wireless@vger.kernel.org
Subject: Re: [PATCH] wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels()
References: <20230413214118.153781-1-toke@toke.dk> <87v8hysrzx.fsf@kernel.org>
        <87bkjqzrdm.fsf@toke.dk>
Date:   Fri, 14 Apr 2023 15:38:13 +0300
In-Reply-To: <87bkjqzrdm.fsf@toke.dk> ("Toke \=\?utf-8\?Q\?H\=C3\=B8iland-J\?\=
 \=\?utf-8\?Q\?\=C3\=B8rgensen\=22's\?\= message of
        "Fri, 14 Apr 2023 12:32:05 +0200")
Message-ID: <87edom7i6i.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

(dropping stable from cc)

Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> writes:

> Kalle Valo <kvalo@kernel.org> writes:
>
>> Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> writes:
>>
>>> This partially reverts commit e161d4b60ae3a5356e07202e0bfedb5fad82c6aa.
>>>
>>> Turns out the channelmap variable is not actually read-only, it's modif=
ied
>>> through the MCI_GPM_CLR_CHANNEL_BIT() macro further down in the functio=
n,
>>> so making it read-only causes page faults when that code is hit.
>>>
>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D217183
>>> Fixes: e161d4b60ae3 ("wifi: ath9k: Make arrays prof_prio and
>>> channelmap static const")
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen <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.

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

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatc=
hes