linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Eric Biggers <ebiggers@kernel.org>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org
Subject: Re: AUTOSEL process
Date: Sat, 11 Mar 2023 13:07:09 -0500	[thread overview]
Message-ID: <ZAzDTVluocRvZ8W8@sashalap> (raw)
In-Reply-To: <734c9a0920f293c88168f38c1245e779d03f4364.camel@HansenPartnership.com>

On Sat, Mar 11, 2023 at 10:54:36AM -0500, James Bottomley wrote:
>On Sat, 2023-03-11 at 08:41 -0500, Sasha Levin wrote:
>> On Fri, Mar 10, 2023 at 03:07:04PM -0800, Eric Biggers wrote:
>> > On Mon, Feb 27, 2023 at 07:41:31PM -0800, Eric Biggers wrote:
>> > >
>> > > Well, probably more common is that prerequisites are in the same
>> > > patchset, and the prerequisites are tagged for stable too. 
>> > > Whereas AUTOSEL often just picks patch X of N.  Also, developers
>> > > and maintainers who tag patches for stable are probably more
>> > > likely to help with the stable process in general and make sure
>> > > patches are backported correctly...
>> > >
>> > > Anyway, the point is, AUTOSEL needs to be fixed to stop
>> > > inappropriately cherry-picking patch X of N so often.
>> > >
>> >
>> > ... and AUTOSEL strikes again, with the 6.1 and 6.2 kernels
>> > currently crashing whenever a block device is removed, due to
>> > patches 1 and 3 of a 3-patch series being AUTOSEL'ed (on the same
>> > day I started this discussion, no less):
>> >
>> > https://lore.kernel.org/linux-block/CAOCAAm4reGhz400DSVrh0BetYD3Ljr2CZen7_3D4gXYYdB4SKQ@mail.gmail.com/T/#u
>> >
>> > Oh sorry, ignore this, it's just an anecdotal example.
>>
>> Yes, clearly a problem with AUTOSEL and not with how sad the testing
>> story is for stable releases.
>
>Hey, that's a completely circular argument:  if we had perfect testing
>then, of course, it would pick up every bad patch before anything got
>released; but we don't, and everyone knows it.  Therefore, we have to
>be discriminating about what patches we put in.  And we have to
>acknowledge that zero bugs in patches isn't feasible in spite of all
>the checking we do do.  I also think we have to acknowledge that users
>play a role in the testing process because some bugs simply aren't
>picked up until they try out a release.  So discouraging users from
>running mainline -rc's means we do get bugs in the released kernel that
>we might not have had if they did.  Likewise if everyone only runs
>stable kernels, the bugs in the released kernel don't get found until
>stable.  So this blame game really isn't helping.
>
>I think the one thing everyone on this thread might agree on is that
>this bug wouldn't have happened if AUTOSEL could detect and backport
>series instead of individual patches.  Sasha says that can't be done
>based on in information in Linus' tree[1] which is true but not a
>correct statement of the problem.  The correct question is given all
>the information available, including lore, could we assist AUTOSEL in
>better detecting series and possibly making better decisions generally?

My argument was that this type of issue is no AUTOSEL specific, and we
saw it happening multiple times with stable tagged patches as well.

It's something that needs to get solved, and I suspect that both Greg
and myself will end up using it when it's there.

>I think that's the challenge for anyone who actually wants to help
>rather than complain.  At least the series detection bit sounds like it
>could be a reasonable summer of code project.

Right - I was trying to reply directly to Willy's question: this is
something very useful, somewhat hard, and I don't think I could do in
the near future - so help is welcome here.

-- 
Thanks,
Sasha

  reply	other threads:[~2023-03-11 18:07 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230226034256.771769-1-sashal@kernel.org>
2023-02-26  3:42 ` [PATCH AUTOSEL 6.1 07/21] fs: Use CHECK_DATA_CORRUPTION() when kernel bugs are detected Sasha Levin
2023-02-26  3:42 ` [PATCH AUTOSEL 6.1 12/21] fs/super.c: stop calling fscrypt_destroy_keyring() from __put_super() Sasha Levin
2023-02-26  4:07   ` Eric Biggers
2023-02-26  5:30     ` Eric Biggers
2023-02-26 19:24       ` Eric Biggers
2023-02-26 19:33         ` Slade Watkins
2023-02-27 14:18         ` Sasha Levin
2023-02-27 17:47           ` AUTOSEL process Eric Biggers
2023-02-27 18:06             ` Eric Biggers
2023-02-27 20:39               ` Sasha Levin
2023-02-27 21:38                 ` Eric Biggers
2023-02-27 22:35                   ` Sasha Levin
2023-02-27 22:59                     ` Matthew Wilcox
2023-02-28  0:52                       ` Sasha Levin
2023-02-28  1:25                         ` Eric Biggers
2023-02-28  4:25                           ` Willy Tarreau
2023-03-30  0:08                         ` Eric Biggers
2023-03-30 14:05                           ` Sasha Levin
2023-03-30 17:22                             ` Eric Biggers
2023-03-30 17:50                               ` Sasha Levin
2023-02-28  0:32                     ` Eric Biggers
2023-02-28  1:53                       ` Sasha Levin
2023-02-28  3:41                         ` Eric Biggers
2023-02-28 10:41                           ` Amir Goldstein
2023-02-28 11:28                             ` Greg KH
2023-03-01  2:05                               ` Slade Watkins
2023-03-01  5:13                                 ` Eric Biggers
2023-03-01  6:09                                   ` Greg KH
2023-03-01  7:22                                     ` Eric Biggers
2023-03-01  7:40                                       ` Willy Tarreau
2023-03-01  8:31                                         ` Eric Biggers
2023-03-01  8:43                                           ` Greg KH
2023-03-01  6:06                                 ` Greg KH
2023-03-01  7:05                                   ` Eric Biggers
2023-03-01 10:31                               ` Thorsten Leemhuis
2023-03-01 13:26                               ` Mark Brown
2023-02-28 17:03                           ` Sasha Levin
2023-03-10 23:07                           ` Eric Biggers
2023-03-11 13:41                             ` Sasha Levin
2023-03-11 15:54                               ` James Bottomley
2023-03-11 18:07                                 ` Sasha Levin [this message]
2023-03-12 19:03                                   ` Theodore Ts'o
2023-03-07 21:18               ` Pavel Machek
2023-03-07 21:45                 ` Eric Biggers
2023-03-11  6:25                   ` Matthew Wilcox
2023-03-11  8:11                     ` Willy Tarreau
2023-03-11 11:45                       ` Pavel Machek
2023-03-11 12:29                         ` Greg KH
2023-03-21 12:41                           ` Maciej W. Rozycki
2023-03-11 14:06                     ` Sasha Levin
2023-03-11 16:16                       ` Theodore Ts'o
2023-03-11 17:48                         ` Eric Biggers
2023-03-11 18:26                           ` Sasha Levin
2023-03-11 18:54                             ` Eric Biggers
2023-03-11 19:01                               ` Eric Biggers
2023-03-11 21:14                               ` Sasha Levin
2023-03-12  8:04                                 ` Amir Goldstein
2023-03-12 16:00                                   ` Sasha Levin
2023-03-13 17:41                               ` Greg KH
2023-03-13 18:54                                 ` Eric Biggers
2023-03-14 18:26                                   ` Greg KH
2023-03-11 20:17                             ` Eric Biggers
2023-03-11 21:02                               ` Sasha Levin
2023-03-12  4:23                                 ` Willy Tarreau
2023-03-11 18:33                           ` Willy Tarreau
2023-03-11 19:24                             ` Eric Biggers
2023-03-11 19:46                               ` Eric Biggers
2023-03-11 20:19                                 ` Willy Tarreau
2023-03-11 20:59                                   ` Sasha Levin
2023-03-11 20:11                               ` Willy Tarreau
2023-03-11 20:53                                 ` Eric Biggers
2023-03-12  4:32                                   ` Willy Tarreau
2023-03-12  5:21                                     ` Eric Biggers
2023-03-12  5:48                                       ` Willy Tarreau
2023-03-12  7:42                                       ` Amir Goldstein
2023-03-12 13:34                                         ` Mark Brown
2023-03-12 15:57                                         ` Sasha Levin
2023-03-12 13:55                                 ` Mark Brown
2023-03-11 22:38                       ` David Laight
2023-03-12  4:41                         ` Willy Tarreau
2023-03-12  5:09                           ` Theodore Ts'o
2023-03-14 14:12                             ` Jan Kara
2023-03-13  3:37             ` Bagas Sanjaya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZAzDTVluocRvZ8W8@sashalap \
    --to=sashal@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=ebiggers@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).