@krzk @sj Also note that the largest generator of CVEs for the kernel is RH doing so for their kapot engineering process which requires a CVE to be created to backport a patch easier to their old "enterprise" kernel tree. That means they are usually creating new CVEs for issues we fixed months/years ago. Hopefully one day they fix their process (I document it in detail in the presentation @krzk linked to above).

When your server is doing too many builds at once...

@Foxboron @torvalds Like perhaps this one: https://lore.kernel.org/r/20230817204523.never.034-kees@kernel.org

@Foxboron @torvalds I would, but it's not for a subsystem I maintain, sorry. Try finding something that I am responsible for and I'll be glad to take it.

@niclas @Foxboron @torvalds To quote the GPLv2:

"The source code for a work means the preferred form of the work for making modifications to it."

I doubt printouts are how you handle the source in a way that you are able to make modifications to it :)

@dvzrv @Foxboron @torvalds Kernel patch reviews are almost always better done with drinks. Calms the reviewer into not getting as upset as they normally would...

@Foxboron @torvalds Oh, and bonus points for the dot-matrix printer with the perforated paper! That shows dedication to both keeping such a beast alive with a working ribbon, as well as having paper for the thing.

@dvzrv @Foxboron @torvalds There is way more stuff in the kernel that started out over drinks with "I bet you couldn't do that!" than we would like to admit, so you are continuing a long and proud tradition!

@Foxboron @torvalds If you can import that into git, I will be impressed :)

On the always good https://kottke.org/ the other day, there was a link to a series of videos of professional drummers hearing songs for the first time, without the drum track, and then playing what they think would fit. Here's one of them, https://www.youtube.com/watch?v=tbUYVcaF_l0 and while I'm not a drummer, the best part of this is how Dirk Verbeuren explains the process of listening to the song, and how to learn something never seen before and how to adapt to it. The whole series is recommended: https://www.youtube.com/playlist?list=PLThYwnIoLwyWiF5RgHPzOzYNdqQw1-tep

Anyway, got me to thinking, a while ago a friend (also a kernel developer) had the idea of a presentation for the yearly Kernel Recipes conference that would be him sending me a patch, me reviewing it, talking about how it is reviewed, and the back and forth between us on getting it into a mergable state. That process is one that someone else recently asked me "what presentations can you recommend for new kernel developers to explain how this review process works" and I didn't have any suggestions, but it really is an important thing that is not taught at all in school, or in any company that I know of.

So maybe, a series of videos, or talks, where a maintainer gets a patch series and walks through how they review it, what they look for, what they expect, and how its tested (if at all), might be interesting? Or "here's a reported bug, how do you debug it?" type of presentation to put a developer through the steps of attacking something unknown, and figuring out what the problem is, and how it could possibly be solved.

Brings me back to the days of the Plumbers conference session where we had "bring us your laptop and we will get suspend/resume to work on it" tracks that ended up being a lot of fun for everyone involved as crazy hardware/bios issues were debugged live.

Would this even be interesting? I think it might need a lot of good editing, you don't want to see me staring numly at a terminal window for a few hours while reading lots of inscrutable driver code tracing it to find a bug, that would put everyone to sleep...

@basisbit @kernellogger All depends on your workload, test it yourself to see.

@kernellogger You forgot the Xen bugfix in there too, 3 things at once!

@kernellogger It's patch Tuesday! {sigh} This has been a pain to get done, odds are it will take a few more cycles and fixups once it hits real testing...

RE: https://fosstodon.org/users/kernellogger/statuses/110855114931496454

@T_X @kernellogger Current process is really complex, it literally is "Last kernel release of the year".

I have added a caveat when companies / developers abuse the end-of-year release deadline by throwing in crud too early that adds "If the last release of the year is just too unstable, I will pick the previous release instead." and that usually keeps people honest as no one wants to loose 3 months of work.

Been this way for many years now, it's well-known by the distros. It's up to them to decide to sync up with these releases or not, nothing I can do to force them to, except to point out that distros that do not are usually totally insecure and buggy and cost more to maintain, but that was their choice to make :)

@w8emv @kernellogger Try it yourself and find out!

Everything is now public for you to test with, and as always, different workloads have different impacts, so anything I might say, might not be relevant for your usage model at all.

@kernellogger stable kernels now released with those fixes, if people need them (hint, microcode updates are better...)

@krzk @kernellogger Android devices do this as they do control the bootloader, and they control their individual drivers, BUT not the core kernel image/source. sysfs interfaces are forbidden by default by the SELinux rules and adding an exception for an Android device for them is a real pain (which is a good thing.) So they default to command line options as it's trivial to do that in a driver and for them, it works well (again, full control over the command line options.)

But that isn't an acceptable interface for upstream, for all the same reasons :)

@jani @kernellogger Modifying the command line is hard, if not impossible, for almost everyone other than a developer. So for a developer, sure, use a module parameter for crazy debugging stuff. but NEVER ask a user to use it for a normal operation, or for something that you should be doing in a per-device way.

@kernellogger If wearing a shirt with that on it actually made a difference, I'm all for it, but odds are, the people who I need to say this to wouldn't see it...

@sj @krzk @kernellogger @minipli I have ALWAYS said that 4 week old results are better than no results at all. Especially if regressions are found, which is the most important thing to detect.

I get many "private" emails from companies that do 1-2 month syncs of the LTS branches in their private SoC trees usually saying "all is good!" which gets them into the habit of doing testing. And every once in a while, they do find a regression, which we work quickly to resolve (many times it's just "use the next version, this was already caught...)

So yes, merge with LTS, test, and let me know the results please.