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

@carrabelloy @kernellogger @krzk We don't need your money, we just need you to test stable kernels (and Linus's kernels) and tell us all is good, or if something breaks!

@kernellogger @krzk You are exactly correct here. I hear it all the time, "your stable kernels aren't as tested as our Enterprise kernels are", resulting in "so why don't you test them and let me know the results" for which I never get an answer.

{sigh}

@kernellogger "We want everything stable, except for this one new feature we MUST have" X thousands of customers = "enterprise kernel monster"

Or to quote someone wise, "Everybody wants progress, nobody wants change."

@minipli @kernellogger CVEs are pointless and mean nothing for kernel patches, this shouldn't be news to you, see my talk from years ago for details, and it's only gotten worse since then: https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/

@platymew @jstultz this is WITH data lines, I can run a USB camera and microphone just fine with this.

Thanks to @jstultz for showing that the monstrosity of USB A-C-A with a magnetic C connector in the middle actually works! Saves me constantly having to plug/unplug my microphone and camera every other day into my well-worn USB hub.

John did it much better with one less adapter than I so this stack could be smaller if needed, but this is all I could find locally.

First talk I've given in person in a very long time, and it's on legal issues (the EU Cyber Resilience Act), I must have done something wrong in a past life:
https://kccnceu2023.sched.com/event/1Lnv0

Should be fun, if you are at KubeCon, stop by and ask questions, it's meant to be a discussion. A recording will be made public afterwards too.

bpftrace fun question of the week I’ve been beating my head against for a while now.

Given the following bpftrace program:

tracepoint:syscalls:sys_enter_open,
tracepoint:syscalls:sys_enter_openat
{
        $g = "magic_command_to_exit_trace";
        $s = str(args->filename);
        printf("%s\n", $s);
        if ($s == $g) {
                exit();
        }
}

I get the lovely warning:

WARNING: Addrspace mismatch
    if ($s == $g) {

which I can understand. But what I can’t figure out is how to resolve this (hint, the program works just fine, when opening the “magic” file, the trace exits), as how to turn a literal string into the proper address space that args->filename is?

I’ve dug into too many bpftrace git commits to try to figure it out, to no luck. Anyone have a hint?

Oh, and if you want to see where this is used, it’s in this “fun” script: https://github.com/gregkh/gregkh-linux/blob/master/scripts/trace_kernel_build.sh

Warning, realpath takes a long time when processing millions of files, be patient when running the script.

@brauner @monsieuricon In looking at the NL list, too many things on there that might trigger spam filters, or at the very least, rightly make people upset, so I'll stick with the default list for now.

@brauner @monsieuricon Nice! You know you can localize the dice words, there's a wordlist_de.txt file in the package already on the distro I use, now to find a _nl.txt version...

@bert_hubert @Lot_ten Succes!

There's been a long nerd-sniping thread recently here from @monsieuricon where email message-ids were being discussed and generated in semi-interesting ways that ended up detouring me and @brauner into writing up competing python vs. perl scripts to get `git send-email` to properly use our new bespoke message ids:
https://social.kernel.org/notice/AU5IphRPUsQvvkx732

But why does any of this matter? As most everyone knows, Linux kernel development happens through email, and the Message-Id of an email is a unique identifier that is used to track messages in our patch handling tools and archives (see https://lore.kernel.org for the archives.) By crafting shorter-but-still-unique message ids it's easier to reference those messages in other places, and using words is just prettier overall than random UUID values (https://i.redd.it/64gl4t9s52ra1.jpg for an example)

Bonus to all of this is that people don't realize that most of the patches we send out are actually signed and can be validated as coming from the person that sent them. The tool we use for that looks at the body of the email, and a small subset of the Header tags in the email. By providing to the tool our custom Message-Id, that adds yet another portion of the email that is now able to be signed and validated, providing a tiny bit more security overall in the patch submission processes (very very tiny, I know, but it's real, as I found out when I submitted a patch with a broken message-id from what was signed and our tools caught it.)

Anyway, all of that is a long way of showing off a tiny core change to the kernel that allows some core structures to be moved to read-only memory that I've been working on for a few months now. Here's the last portion of that work being sucked off of the email archives and validated as coming from me:

@brauner @dakkar @monsieuricon
Ok, all now working properly, and bonus, the message-id is now part of the signature on the email itself!

@vbabka @brauner @dakkar @monsieuricon Yes, it's better than the "write once, and then rewrite again, and again, and again as the language updates itself and breaks previously-working scripts over the years" :)