public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Oleksandr Natalenko <oleksandr@natalenko.name>,
	Kent Overstreet <kent.overstreet@linux.dev>,
	Jiri Benc <jbenc@redhat.com>,
	stable@vger.kernel.org,
	Thorsten Leemhuis <regressions@leemhuis.info>
Subject: Re: fs/bcachefs/
Date: Wed, 21 Feb 2024 17:58:30 -0500	[thread overview]
Message-ID: <ZdaAFt_Isq9dGMtP@sashalap> (raw)
In-Reply-To: <aaf2f030-b6f4-437b-bb4e-79aa4891ae56@suse.cz>

On Wed, Feb 21, 2024 at 07:10:02PM +0100, Vlastimil Babka wrote:
>On 2/21/24 18:57, Greg KH wrote:
>> On Wed, Feb 21, 2024 at 05:00:05PM +0100, Oleksandr Natalenko wrote:
>>> On středa 21. února 2024 15:53:11 CET Greg KH wrote:
>>> > 	Given the huge patch volume that the stable tree manages (30-40 changes
>>> > 	accepted a day, 7 days a week), any one kernel subsystem that wishes to
>>> > 	do something different only slows down everyone else.
>>>
>>> Lower down the volume then? Raise the bar for what gets backported?
>>> Stable kernel releases got unnecessarily big [1] (Jiří is in Cc).
>>> Those 40 changes a day cannot get a proper review. Each stable release
>>> tries to mimic -rc except -rc is in consistent state while "stable" is
>>> just a bunch of changes picked here and there.
>>
>> If you can point out any specific commits that we should not be taking,
>> please let us know.
>>
>> Personally I think we are not taking enough, and are still missing real
>> fixes.  Overall, this is only a very small % of what goes into Linus's
>> tree every day, so by that measure alone, we know we are missing things.
>
>What % of what goes into Linus's tree do you think fits within the rules
>stated in Documentation/process/stable-kernel-rules.rst ? I don't know but
>"very small" would be my guess, so we should be fine as it is?
>
>Or are the rules actually still being observed? I doubt e.g. many of the
>AUTOSEL backports fit them? Should we rename the file to
>stable-rules-nonsense.rst?

Hey, I have an exercise for you which came up last week during the whole
CVE thing!

Take a look at a random LTS kernel (I picked 5.10), in particular at the
CVEs assigned to the kernel (in my case I relied on
https://github.com/nluedtke/linux_kernel_cves/blob/master/data/5.10/5.10_security.txt).

See how many of those actually have a stable@ tag to let us know that we
need to pull that commit. (spoiler alert: in the 5.10 case it was ~33%)

Do you have a better way for us to fish for the remaining 67%?

Yeah, some have a Fixes tag, (it's not in stable-kernel-rules.rst!), and
in the 5.10 case it would have helped with about half of the commits,
but even then - what do we do with the remaining half?

The argument you're making is in favor of just ignoring it until they
get a CVE assigned (and even then, would we take them if it goes against
stable-kernel-rules.rst?), but then we end up leaving users exposed for *years*
as evidenced by some CVEs.

So if we go with the current workflow, folks complain that we take too
many patches. If we were to lean strictly to what
stable-kernel-rules.rst says, we'd apparently miss most of the
(security) issues affecting users.

-- 
Thanks,
Sasha

  parent reply	other threads:[~2024-02-21 22:58 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-15 22:12 fs/bcachefs/ Kent Overstreet
2024-01-15 23:03 ` fs/bcachefs/ Sasha Levin
2024-02-20 17:23   ` fs/bcachefs/ Kent Overstreet
2024-02-20 18:03     ` fs/bcachefs/ Greg KH
2024-02-20 18:53       ` fs/bcachefs/ Greg KH
2024-02-20 20:06         ` fs/bcachefs/ Kent Overstreet
2024-02-20 20:19           ` fs/bcachefs/ Greg KH
2024-02-20 20:22             ` fs/bcachefs/ Kent Overstreet
2024-02-20 20:39               ` fs/bcachefs/ Greg KH
2024-02-20 20:42                 ` fs/bcachefs/ Kent Overstreet
2024-02-20 20:39             ` fs/bcachefs/ Kent Overstreet
2024-02-20 20:51               ` fs/bcachefs/ Greg KH
2024-02-20 21:00                 ` fs/bcachefs/ Kent Overstreet
2024-02-21 14:53                   ` fs/bcachefs/ Greg KH
2024-02-21 16:00                     ` fs/bcachefs/ Oleksandr Natalenko
2024-02-21 17:57                       ` fs/bcachefs/ Greg KH
2024-02-21 18:10                         ` fs/bcachefs/ Vlastimil Babka
2024-02-21 20:52                           ` fs/bcachefs/ Kent Overstreet
2024-02-21 22:58                           ` Sasha Levin [this message]
2024-02-21 23:12                             ` fs/bcachefs/ Kent Overstreet
2024-02-22  5:48                               ` fs/bcachefs/ Greg KH
2024-02-22  6:30                                 ` fs/bcachefs/ Kent Overstreet
2024-02-22 11:54                                   ` fs/bcachefs/ Sasha Levin
2024-02-21 23:47                             ` fs/bcachefs/ Oleksandr Natalenko
2024-02-22 19:19                           ` stable-kernel-rules was fs/bcachefs/ Pavel Machek
2024-02-22 22:33                             ` Kent Overstreet
2024-02-23 18:50                               ` Pavel Machek
2024-02-20 19:36     ` fs/bcachefs/ Sasha Levin
2024-01-16 14:13 ` fs/bcachefs/ Greg KH
2024-01-16 17:26   ` fs/bcachefs/ Kent Overstreet
2024-01-16 17:44     ` fs/bcachefs/ Greg KH

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=ZdaAFt_Isq9dGMtP@sashalap \
    --to=sashal@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jbenc@redhat.com \
    --cc=kent.overstreet@linux.dev \
    --cc=oleksandr@natalenko.name \
    --cc=regressions@leemhuis.info \
    --cc=stable@vger.kernel.org \
    --cc=vbabka@suse.cz \
    /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