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
next prev 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