Re: fs/bcachefs/

[Oleksandr Natalenko <oleksandr@natalenko.name>]

[-- Attachment #1: Type: text/plain, Size: 3407 bytes --]

On středa 21. února 2024 23:58:30 CET Sasha Levin wrote:
> 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%?

With all due respect, once a measure becomes a target, it ceases to be a good measure.

> 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.

It's not a catastrophic problem to miss fixes, you will never be able to reach 100% anyway, guaranteed. Introducing a new, untested and not reviewed code on scale is a bigger problem. Yes, backports should be considered as a new code that needs appropriate review. Regardless of how skilled you two are, it's not a task for you. There must be another way of doing this.

-- 
Oleksandr Natalenko (post-factum)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]