* [PATCH] wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels()
@ 2023-04-13 21:41 Toke Høiland-Jørgensen
2023-04-14 10:00 ` Kalle Valo
2023-04-19 14:24 ` Kalle Valo
0 siblings, 2 replies; 5+ messages in thread
From: Toke Høiland-Jørgensen @ 2023-04-13 21:41 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Kalle Valo, Colin Ian King
Cc: linux-wireless, stable
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>
---
drivers/net/wireless/ath/ath9k/mci.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/mci.c b/drivers/net/wireless/ath/ath9k/mci.c
index 3363fc4e8966..a0845002d6fe 100644
--- a/drivers/net/wireless/ath/ath9k/mci.c
+++ b/drivers/net/wireless/ath/ath9k/mci.c
@@ -646,9 +646,7 @@ void ath9k_mci_update_wlan_channels(struct ath_softc *sc, bool allow_all)
struct ath_hw *ah = sc->sc_ah;
struct ath9k_hw_mci *mci = &ah->btcoex_hw.mci;
struct ath9k_channel *chan = ah->curchan;
- static const u32 channelmap[] = {
- 0x00000000, 0xffff0000, 0xffffffff, 0x7fffffff
- };
+ u32 channelmap[] = {0x00000000, 0xffff0000, 0xffffffff, 0x7fffffff};
int i;
s16 chan_start, chan_end;
u16 wlan_chan;
--
2.40.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels()
2023-04-13 21:41 [PATCH] wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels() Toke Høiland-Jørgensen
@ 2023-04-14 10:00 ` Kalle Valo
2023-04-14 10:32 ` Toke Høiland-Jørgensen
2023-04-19 14:24 ` Kalle Valo
1 sibling, 1 reply; 5+ messages in thread
From: Kalle Valo @ 2023-04-14 10:00 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Kalle Valo, Colin Ian King, linux-wireless, stable
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 :)
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels()
2023-04-14 10:00 ` Kalle Valo
@ 2023-04-14 10:32 ` Toke Høiland-Jørgensen
0 siblings, 0 replies; 5+ messages in thread
From: Toke Høiland-Jørgensen @ 2023-04-14 10:32 UTC (permalink / raw)
To: Kalle Valo; +Cc: Kalle Valo, Colin Ian King, linux-wireless, stable
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! :/
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)...
-Toke
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels()
2023-04-13 21:41 [PATCH] wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels() Toke Høiland-Jørgensen
2023-04-14 10:00 ` Kalle Valo
@ 2023-04-19 14:24 ` Kalle Valo
2023-04-19 15:18 ` Colin King (gmail)
1 sibling, 1 reply; 5+ messages in thread
From: Kalle Valo @ 2023-04-19 14:24 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Toke Høiland-Jørgensen, Kalle Valo, Colin Ian King,
linux-wireless, stable
Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 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>
> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Patch applied to ath-next branch of ath.git, thanks.
b956e3110a79 wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels()
--
https://patchwork.kernel.org/project/linux-wireless/patch/20230413214118.153781-1-toke@toke.dk/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels()
2023-04-19 14:24 ` Kalle Valo
@ 2023-04-19 15:18 ` Colin King (gmail)
0 siblings, 0 replies; 5+ messages in thread
From: Colin King (gmail) @ 2023-04-19 15:18 UTC (permalink / raw)
To: Kalle Valo, Toke Høiland-Jørgensen
Cc: Kalle Valo, linux-wireless, stable
On 19/04/2023 15:24, Kalle Valo wrote:
> Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
>> 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>
>> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
>
> Patch applied to ath-next branch of ath.git, thanks.
>
> b956e3110a79 wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels()
>
Thanks. Apologies for the regression. My bad.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-04-19 15:25 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-04-13 21:41 [PATCH] wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels() Toke Høiland-Jørgensen
2023-04-14 10:00 ` Kalle Valo
2023-04-14 10:32 ` Toke Høiland-Jørgensen
2023-04-19 14:24 ` Kalle Valo
2023-04-19 15:18 ` Colin King (gmail)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).