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:
signature.asc
Description: This is a digitally signed message part.
