On Tue, 13 Jul 2021 08:31:57 +0200 Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> 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@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. 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.
