Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <2b1b798e-8449-11e-e2a1-daf6a341409b@google.com>
 <YO0zXVX9Bx9QZCTs@kroah.com> <20210713182813.2fdd57075a732c229f901140@linux-foundation.org>
 <YO6r1k7CIl16o61z@kroah.com> <YO7sNd+6Vlw+hw3y@sashalap> <YO8EQZF4+iQ13QU/@mit.edu>
 <YO8Gzl2zmg8+R8Uu@kroah.com> <YO8dN9U7J2bi1gkf@mit.edu> <YO8gFgQIRYvCODBT@kroah.com>
In-Reply-To: <YO8gFgQIRYvCODBT@kroah.com>
From:   Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Thu, 15 Jul 2021 11:01:04 +0200
Message-ID: <CAMuHMdUi+HsApqRwBDBFnfnAOs9EprDh5HCV4UncEL_cnXZasA@mail.gmail.com>
Subject: Re: 5.13.2-rc and others have many not for stable
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     "Theodore Y. Ts'o" <tytso@mit.edu>,
        Sasha Levin <sashal@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Michal Hocko <mhocko@kernel.org>,
        Hugh Dickins <hughd@google.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Mike Kravetz <mike.kravetz@oracle.com>,
        Miaohe Lin <linmiaohe@huawei.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux MM <linux-mm@kvack.org>, stable <stable@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Greg et al,

On Wed, Jul 14, 2021 at 7:36 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Wed, Jul 14, 2021 at 01:21:59PM -0400, Theodore Y. Ts'o wrote:
> > On Wed, Jul 14, 2021 at 05:46:22PM +0200, Greg Kroah-Hartman wrote:
> > > The number of valid cases where someone puts a "Fixes:" tag, and that
> > > patch should NOT be backported is really really slim.  Why would you put
> > > that tag and not want to have known-broken kernels fixed?
> > >
> > > If it really is not an issue, just do not put the "Fixes:" tag?
> >
> > I think it really boils down to what the tags are supposed to mean and
> > what do they imply.
> >
> > The argument from the other side is if the Stable maintainers are
> > interpreting the Fixes: tag as an implicit "CC: stable", why should we
> > have the "Cc: stable" tag at all in that case?
>
> I would love to not have to look at the Fixes: tag, but today we have to
> because not all subsystems DO use cc: stable.
>
> We miss loads of real fixes if we only go by cc: stable right now.  If
> you can go and fix those subsystems to actually remember to do this
> "properly", wonderful, we will not have to mess with only Fixes: tags
> again.
>
> But until that happens, we have to live with what we have.  And all we
> have are "hints" like Fixes: to go off of.

IMHO the biggest issues with "Cc: stable" are that (a) in general
it's hard to know if a patch is (not) worthwhile to be backported,
and (b) without a Fixes: tag it doesn't tell you what version(s)
it should be applied to.

Just having a Fixes: tag fixes the latter, and allows you to defer
the decision to backport.

> > We could also have the policy that in the case where you have a fix
> > for a bug, but it's super subtle, and shouldn't be automatically
> > backported, that the this should be explained in the commit, e.g.,
> >
> >    This commit fixes a bug in "1adeadbeef33: lorem ipsum dolor sit
> >    amet" but it is touching code which subtle and quick to anger, the
> >    bug isn't all that serious.  So please don't backport it
> >    automatically; someone should manually do the backport and run the
> >    fooblat test before sumitting it to the stable maintainers.
>
> That's wonderful, I would love to see that more, and we do see that on
> some commits.  And we mostly catch them (I miss them at times, but
> that's my fault, not the developer/maintainers fault.)

In my experience, the hardest cases are the ones where a patch fixes
a real bug, but the fix has an obscure implicit dependency on another
commit in a different subsystem (e.g. driver and DTS interaction).
When backporting, a regression is introduced if the dependency
is not present yet in the stable tree.

> > Andrew seems to be of the opinion that these sorts of cases are very
> > common.  I don't have enough data to have a strong opinion either way.
> > But if you are right that it is a rare case, then sure, simply
> > omitting the Fixes: tag and using text in the commit description would
> > work.  We just need to agree that this is the convention that we all
> > shoulf be using.
> >
> > I still wonder though what's the point of having the "Cc: stable" tag
> > if it's implicitly assumed to be there if there is a Fixes: tagle.
>
> Because cc: stable came first, and for some reason people think that it
> is all that is necessary to get patches committed to the stable tree,
> despite it never being documented or that way.  I have to correct
> someone about this about 2x a month on the stable@vger list.

For a developer, it's much easier to not care about "Cc: stable"
at all, because as soon as you add a "Cc: stable" to a patch, or CC
stable, someone will compain ;-)  Much easier to just add a Fixes: tag,
and know it will be backported to trees that have the "buggy" commit.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds