Re: 5.13.2-rc and others have many not for stable

[Greg Kroah-Hartman]

On Mon, Jul 12, 2021 at 10:55:01PM -0700, Hugh Dickins wrote:
> On Mon, 12 Jul 2021, Greg Kroah-Hartman wrote:
> 
> > This is the start of the stable review cycle for the 5.13.2 release.
> > There are 800 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed, 14 Jul 2021 06:02:46 +0000.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.13.2-rc1.gz
> > or in the git tree and branch at:
> > 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.13.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> > -------------
> > Pseudo-Shortlog of commits:
> > 
> > Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> >     Linux 5.13.2-rc1
> 
> Hi Greg,
> 
> Sorry to be making waves, but please, what's up with the 5.13.2-rc,
> 5.12.17-rc, 5.10.50-rc, 5.4.132-rc stable release candidates?

They show the problem that we currently have where maintainers wait at
the end of the -rc cycle and keep valid fixes from being sent to Linus.
They "bunch up" and come out only in -rc1 and so the first few stable
releases after -rc1 comes out is huge.  It's been happening for the past
few years and only getting worse.  These stable releases are proof of
that, the 5.13.2-rc release was the largest we have ever done and it
broke one of my scripts because of it :(

I know personally I do this for my subsystems, having fixes that are
trivial things batch up for -rc1 just because they are generally not
worth getting into -final.  But that is not the case with many other
subsystems as you can see by these huge patch sequences.

> 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@xxxxxxxxxx/
> 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@xxxxxxxxxx>
> >     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.

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?  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.

We are glad to drop any patch added to a -rc release, just let us know.
We are also glad to revert them later on if a developer/maintainer does
not catch them in time before a release happens.

thanks,

greg k-h