lkml.org 
[lkml]   [2021]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 5.13.2-rc and others have many not for stable
On Tue, 13 Jul 2021 08:31:57 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

>
> > Amongst the 2000+ patches posted today, there are a significant number
> > of them Signed-off-by Andrew, Signed-off-by Linus, Signed-off-by Sasha:
> > yet never Cc'ed to stable (nor even posted as AUTOSELs, I think).
> >
> > Am I out of date? I thought that had been agreed not to happen:
> > https://lore.kernel.org/linux-mm/20190808000533.7701-1-mike.kravetz@oracle.com/
> > is the thread I found when I looked for confirmation, but I believe the
> > same has been agreed before and since too.
> >
> > Andrew goes to a lot of trouble to establish which Fixes from his tree
> > ought to go to stable. Of course there will be exceptions which we
> > later decide should go in after all; but it's worrying when there's a
> > wholesale breach like this, and I think most of them should be dropped.
> >
> > To pick on just one of many examples (sorry Miaohe!), a patch that
> > surprises me, but I've not had time to look into so far, and would
> > not want accelerated into X stable releases, 385/800
> >
> > > Miaohe Lin <linmiaohe@huawei.com>
> > > mm/shmem: fix shmem_swapin() race with swapoff
>
> Sasha, and I, take patches from Linus's tree like the above one that
> have "Fixes:" tags in them as many many maintainers do not remember to
> put "cc: stable" on their patches.

As do many many developers. I always check.

> The above patch says it fixes a problem in the 5.1 kernel release, so
> Sasha queued it up for 5.10, 5.12, and 5.13. Odds are he should have
> also sent a "FAILED" notice for 5.4, but we don't always do that for
> patches only with a Fixes tag all the time as we only have so much we
> can do...
>
> So is that tag incorrect? If not, why was it not cc: stable? Why is it
> not valid for a stable release?

Usually because we judged that the seriousness of the problem did not
justify the risk & churn of backporting its fix.

> So far, all automated testing seems to
> show that there are no regressions in these releases with these commits
> in them. If there was a problem, how would it show up?
>
> And as far as I know, mm/ stuff is still not triggered by the AUTOSEL
> bot, but that is not what caused this commit to be added to a stable
> release.
>
> Trying to keep a "do not apply" list for Fixes: tags only is much harder
> for both of us as we do these semi-manually and review them
> individually. Trying to remember what subsystem only does Fixes tags
> yet really doesn't mean it is an impossible task.

Well, it shouldn't be super hard to skip all patches which have Fixes:,
Signed-off-by:akpm and no cc:stable?

I'd really really prefer this, please. At present this -stable
promiscuity is overriding the (sometime carefully) considered decisions
of the MM developers, and that's a bit scary. I've actually been
spending the past couple of years believing that if I left off
cc:stable, the fix wasn't going to go into -stable!

Alternatively I could just invent a new tag to replace the "Fixes:"
("Fixes-no-backport?") to be used on patches which fix a known previous
commit but which we don't want backported.


\
 
 \ /
  Last update: 2021-07-14 03:29    [W:0.205 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site