[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com>
Date: Thu, 20 Apr 2023 15:27:09 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Toke Høiland-Jørgensen <toke@...e.dk>
Cc: linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
Colin Ian King <colin.i.king@...il.com>,
Thorsten Leemhuis <regressions@...mhuis.info>,
Jakub Kicinski <kuba@...nel.org>,
Kalle Valo <kvalo@...nel.org>,
Linux kernel regressions list <regressions@...ts.linux.dev>
Subject: Re: One-off regression fix for 6.3 [was: Re: [PATCH] wifi: ath9k:
Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels()]
On Thu, Apr 20, 2023 at 2:09 PM Toke Høiland-Jørgensen <toke@...e.dk> wrote:
>
> 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.
Sure. I'm always open to direct fixes when there is no controversy
about the fix. No problem. I still happily deal with individual
patches.
And yes, I do consider "regression in an earlier release" to be a
regression that needs fixing.
There's obviously a time limit: if that "regression in an earlier
release" was a year or more ago, and just took forever for people to
notice, and it had semantic changes that now mean that fixing the
regression could cause a _new_ regression, then that can cause me to
go "Oh, now the new semantics are what we have to live with".
But something like this, where the regression was in the previous
release and it's just a clear fix with no semantic subtlety, I
consider to be just a regular regression that should be expedited -
partly to make it into stable, and partly to avoid having to put the
fix into _another_ stable kernel..
Linus
Powered by blists - more mailing lists