On Wed, Feb 21, 2024 at 05:58:30PM -0500, 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%? > > 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. No, I'm not in favor of ignoring things either. What I want is better collaboration between subsystem maintainers and you guys. Awhile back I was proposing some sort of shared dashboard where we could all track and annotate which patches should be considered for backporting when, because the current email based workflow sucks. We need to be working together better, which is why I'm so _damn annoyed_ over the crap with the Fixes: tag, and Greg not taking my signed pull request as an atomic unit. You guys shouldn't be doing all this work yourselves; the subsystem maintainers, the people who know the code best, should be involved. But your attitude 100% pushes people away. I need a workflow that works for me, if I'm going to do the backporting for bcachefs patches, as I intend to: fuckups in filesystem land can have _far_ too high a cost for me to leave this work to anyone else. What I need is: - A way to unambigiously tag a patch as something that I need to look at later when I'm doing backports; and I do _not_ want to have to go git blame spelunking when I'm doing that, distracting me from whatever else I'm working on; if you insist on the Fixes: tag conforming to your tools then this won't get done and bugfixes will get lost. - Signed pull requests to not get tweaked and rebased. Tweaking and hand editing patches is one thing when it's being done by the subsystem maintainer, the person who at least nominally knows the code best and is best qualified to review those changes. You guys should not be doing that, because then I have to go back and check your work (and even if you swear you aren't changing the code; how do I know unless I look at the diffs? Remember all the talk about supply chain attacks?) and I'm just not going to do that. That adds too much to my workload, and there's no reason for it. And please, you guys, make a bit more of an effort to work with people, and listen to and address their concerns. I hear _way_ too much grousing in private about -stable bullshit, and despite that I went in to this optimistic that we'd be able to cut past the bullshit and establish a good working relationship. Let's see if we still can...
