#Linux 6.12 is out. For a list of new features see:

* This short LWN story: https://lwn.net/Articles/997958/ (screenshotted)

* Two detailed stories from LWN: https://lwn.net/Articles/990750/ & https://lwn.net/Articles/991301/

* The kernelnewbies page: https://kernelnewbies.org/Linux_6.12

See also the announcement from @torvalds:

https://lore.kernel.org/lkml/CAHk-=wgtGkHshfvaAe_O2ntnFBH3EprNk1juieLmjcF2HBwBgQ@mail.gmail.com/

'"No strange surprises this last week, so we're sticking to the regular release schedule, and that obviously means that the merge window opens tomorrow."'

#kernel #LinuxKernel

{sigh} Go home CodeQL, you are drunk…

int main(int argc, char *argv[])
Poorly documented function: fewer than 2% comments for a function of 129 lines.

Code in question is at: https://github.com/gregkh/usbutils/blob/master/lsusb.c#L3835 if people are curious. It’s as if the tool hasn’t seen C code before…

Dear lazyweb,

For the usbutils project, developers have helpfully set up a bunch of github actions to help with build tests and the like, and it also includes github's "security scanning" toolsets. Unfortunately the output of such tools is pretty useless and unhelpful to a fault.

Example, this "result": https://github.com/gregkh/usbutils/security/code-scanning/2291
which claims "short global name" yet there is no such actual global variable `i` in the codebase at all.

Because of stuff like this, the tools "claim" there are 63 "security" issues in the usbutils project. Since when did using single character names become a security issue, even if we were doing that, but ok...

So, how to turn this off, or better yet, fix the test to not report issues that are actually in the tests themselves?

#usbutils (which contains lsusb and the more modern lsusb.py) 018 is out:

https://lore.kernel.org/all/Zxd0oZefuehqhA7z@kroah.com/

@gregkh writes:

'"For users, the largest change will be that the '-v' option to lsusb will now show the negoitated speed of the device on the bus […], and there is better handling for new device descriptor fields and information in the '-v' output as well."'

So… O’Reilly sent me email today hyping up how my books (really, just the one, I assume) is going to be AI-translated into Spanish and German, with other languages to follow. This was probably inevitable, but I still have concerns.

First: are there no human translators of these languages?

Second: who’s going to proof-read all 1,126 pages to make sure nothing got botched, especially given the technical nature of the content? The readers? Which isn’t even crowd-sourcing: it’s customer-sourcing.

@hikari @mcepl @koopa "well" is "better than any other web-based workflow" yes, gerrit does handle them better that way.

But no way is it better than an email-based review workflow, whereby I can just tear through hundreds of patches in a very short amount of time, all while sitting behind a very slow/laggy internet connection, or totally disconnected (i.e. better for distraction-free work).

As almost no other project is at the rate of change or size of the Linux kernel, gerrit might be wonderful for your smaller one. But for ones that are our size, realize that centralized workflows like gerrit and the like just do not scale at all.

Every language has an optimization operator. In C++ that operator is //'

Gotta say, if an unknown new printer shows up in my print dialog, my first thought won't be "cool, let's try printing to it."

In systemd we started to do more and more Varlink IPC (instead of or 9n addition to D-Bus), and you might wonder what that is all about. In this AllSystemsGo talk I try to explain things a bit, enjoy: https://media.ccc.de/v/all-systems-go-2024-276-varlink-now-

From @gregkh : Rust is going to help us with [CVEs in the Linux Kernel] by eliminating some bug classes.

#RustLang #kr2024

I'm at Kernel Recipes 2024, starting the live blog now https://kernel-recipes.org/en/2024/category/live-blog/

Day 1 Morning: https://kernel-recipes.org/en/2024/2024/09/18/live-blog-day-1-morning/

#KernelRecipes #kr2024

Judging from the absolutely packed out rust sessions I went to at LPC and the very positive support from senior people including especially @gregkh it is super clear to me that rust is here to stay in the kernel and a big part of its future.

Have offered to help (or at least be cc'd in hopes I have time for it :) on mm binding stuff fwiw from the kernel side.

And also I really do have to sit down with rust finally... Maybe advent of code this year...

THIS IS IT!!!

The last hurdle for PREEMPT_RT being merged into mainline has just removed by this pull request. Leaving the door open for PREEMPT_RT to be added to 6.12!

"Defects-in-Depth: Analyzing the Integration of Effective Defenses against One-Day Exploits in Android Kernels" is a great read:
https://www.usenix.org/system/files/usenixsecurity24-maar-defects.pdf

"integrating defense-in-depth mechanisms from the mainline Android kernel could mitigate 84.6% of these exploitation flows"

h/t @rene_mobile
@IAIK

#Linux 6.11 is out:

https://lore.kernel.org/lkml/CAHk-=whVpSHw9+4ov=oLevfv8sPYbh59T_9VKif-6Vqkr41jQA@mail.gmail.com/

'"I'm once again on the road and not in my normal timezone, but it's Sunday afternoon here in Vienna, and 6.11 is out.

The last week was actually pretty quiet and calm, which is nice to see. […]

Anyway, with this, the merge window will obviously open tomorrow, and I already have 40+ pull requests pending. That said, exactly _because_ I'm on the road, it will probably be a fairly slow start […] please be patient."'

#Kernel #LinuxKernel

This "untrusted data" patch series from Benno Lossin is the result of conversations at last weekend's Rust Linux kernel conference in Copenhagen:

https://lore.kernel.org/all/20240913112643.542914-1-benno.lossin@proton.me/

It's not a "silver bullet" for why we should be using rust in the Linux kernel, but it is a "big giant sledgehammer" to help squash and prevent from happening MANY common types of kernel vulnerabilities and bugs (remember, "all input is evil!" and this change forces you to always be aware of that, which is something that C in the kernel does not.)

I had always felt that Rust was the future for what we need to do in Linux, but now I'm sure, because if we can do stuff like this, with no overhead involved (it's all checked at build time), then we would be foolish not to give it a real try.

And yes, I've asked for this for years from the C developers, and maybe we can also do it there, but it's not obvious how and no one has come up with a way to do so. Maybe now they will have some more incentive :)

Must not make a comparison. Really. Must not. But just saying...

Clang Built Linux took literally years of effort. And it's all still C, just a different compiler.

Did anyone really expect Rust for Linux to be a breeze?

I know, I know, apples and oranges.

kangrejos in copenhagen was great, but the absolute 🤯 moment was when I learned that GFP_ stands for get_free_pages

I had no idea. and @gregkh next to me had the same https://xkcd.com/1053/ experience

#kernel

BREAKING: Linus rescinds all 'don't break userland' requirements for mm as he deems memory 'virtual' and therefore not real

Anyone else often find themselves starting a retort/reply to a thread here, only to abandon the effort part way through, because you realize your time is better spent supporting/fixing/making things than trying to educate people who haven't bothered to do any of the most basic level of self-education on the given topic?

#selinux