On Sun, Mar 10, 2024 at 01:51:34PM +0000, Matthew Wilcox wrote:
On Sun, Mar 10, 2024 at 09:19:09AM -0400, Sasha Levin wrote:
On Sun, Mar 10, 2024 at 04:26:14AM +0000, Matthew Wilcox wrote:
> On Sat, Mar 09, 2024 at 09:32:15PM -0500, Sasha Levin wrote:
> > This is a note to let you know that I've just added the patch titled
> >
> > readahead: avoid multiple marked readahead pages
>
> https://lore.kernel.org/all/ZdUUMQOoGtZkyYVO@xxxxxxxxxxxxxxxxxxxx/
>
> Why do I have to tell both you *and* Greg?
Still haven't completed my mind-meld with Greg, sorry.
You don't share a list of patches which have been NAKed for backport?
That seems like a useful bit of process to improve.
But more seriously, I'm going through all the stable tagged commits that
are in limbo given 6.8 will be released later today.
I don't see a revert or a fix for the commit in question, which means
that the reported regression will go into the 6.8 final release, which
we will be asking people to switch to.
If it's not good enough for stable, why is it good enough for 6.8?
Pardon me for prioritising fixing a memory corruption bug over a
performance regression. There's only so many hours in the day.
This isn't about whether you have time or not, but rather that it's been
a longstanding policy that we don't do fix a regression and introduce a
new regression instead.
You don't have to fix the regression, just revert the commit in question
if it indeed introduced a regression you care about.
We can't have a "good enough for upstream but not for -stable" policy.
How can you ask users to upgrade this way?
--
Thanks,
Sasha
