linux-kernel - Re: [PATCH V2] uapi: fix statx attribute value overlap for DAX & MOUNT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201202204045.GM2842436@dread.disaster.area>
Date:   Thu, 3 Dec 2020 07:40:45 +1100
From:   Dave Chinner <david@...morbit.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Miklos Szeredi <miklos@...redi.hu>,
        David Howells <dhowells@...hat.com>,
        Ira Weiny <ira.weiny@...el.com>,
        Eric Sandeen <sandeen@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Miklos Szeredi <mszeredi@...hat.com>,
        linux-fsdevel@...r.kernel.org,
        linux-man <linux-man@...r.kernel.org>,
        linux-kernel@...r.kernel.org, xfs <linux-xfs@...r.kernel.org>,
        linux-ext4@...r.kernel.org, Xiaoli Feng <xifeng@...hat.com>
Subject: Re: [PATCH V2] uapi: fix statx attribute value overlap for DAX &
 MOUNT_ROOT

On Wed, Dec 02, 2020 at 08:06:01PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Dec 02, 2020 at 06:41:43PM +0100, Miklos Szeredi wrote:
> > On Wed, Dec 2, 2020 at 5:24 PM David Howells <dhowells@...hat.com> wrote:
> > >
> > > Miklos Szeredi <miklos@...redi.hu> wrote:
> > >
> > > > Stable cc also?
> > > >
> > > > Cc: <stable@...r.kernel.org> # 5.8
> > >
> > > That seems to be unnecessary, provided there's a Fixes: tag.
> > 
> > Is it?
> > 
> > Fixes: means it fixes a patch, Cc: stable means it needs to be
> > included in stable kernels.  The two are not necessarily the same.
> > 
> > Greg?
> 
> You are correct.  cc: stable, as is documented in
>     https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> ensures that the patch will get merged into the stable tree.
> 
> Fixes: is independent of it.  It's great to have for stable patches so
> that I know how far back to backport patches.
> 
> We do scan all commits for Fixes: tags that do not have cc: stable, and
> try to pick them up when we can and have the time to do so.  But it's
> not guaranteed at all that this will happen.
> 
> I don't know why people keep getting confused about this, we don't
> document the "Fixes: means it goes to stable" anywhere...

Except that is exactly what happens, sometimes within a day of two
of a patch with a Fixes tag hitting Linus' kernel. We have had a
serious XFS regression in the 5.9.9 stable kernel that should never
have happened as a result of exactly this "Fixes = automatically
swept immediately into stable kernels" behaviour. See here for
post-mortem analysis:

https://lore.kernel.org/linux-xfs/20201126071323.GF2842436@dread.disaster.area/T/#m26e14ebd28ad306025f4ebf37e2aae9a304345a5

This happened because these auotmated Fixes scans seem to occur
weekly during -rcX release periods, which means there really is *no
practical difference* between the way the stable process treats
Fixes tags and cc: stable.

Hence instead of developers having some control over "urgent, must
backport now" fixes versus fixes that still need the -rcX
stabilisation and integration testing to shake them out fully, the
regular scans result in everything with a fixes tag is treated as an
"urgent, must backport now" category of fix. It effectively
removes the stabilisation and integration testing process from
the changes stable kernel users are being exposed to...

That's not right. It gives upstream developers no margin for error,
and it exposes stable kernel users to bugs that the normal upstream
kernel stabilisation process prevents users from ever seeing in
released kernels. And it is exactly this behaviour that lead people
to understand that "fixes" and "cc: stable" essentially mean the
same thing from a stable kernel perspective.

It seems like this can all be avoided simply by scheduling the
automated fixes scans once the upstream kernel is released, not
while it is still being stabilised by -rc releases. That way stable
kernels get better tested fixes, they still get the same quantity of
fixes, and upstream developers have some margin to detect and
correct regressions in fixes before they get propagated to users.

It also creates a clear demarcation between fixes and cc: stable for
maintainers and developers: only patches with a cc: stable will be
backported immediately to stable. Developers know what patches need
urgent backports and, unlike developers, the automated fixes scan
does not have the subject matter expertise or background to make
that judgement....

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com