Some days it's great to get a patch series like this in your inbox: https://lore.kernel.org/all/20250912081718.3827390-1-tzungbi@kernel.org/ implementing a feature to resolve so many reference count issues that a number of us kernel developers have been grumbling about for years.

Bonus is that it "looks like" the pattern that the Rust implementation in the kernel uses so switching between the two languages shouldn't be that difficult as the terminology and usage is not so different.

Pro tip, when sending a bug to the kernel security team, and it's reviewed and shown to not actually be a bug at all due to the report being "written" by a llm which can't actually parse C very well, don't proceed to "curse" the reviewer for pointing this out.

{sigh}

The other day me and @gregkh shot down a draft proposal to add a new role in the CVE ecosystem (SADP: "supplier ADP") that would append data to CVEs with details about dependencies and how they are or are not vulnerable to each particular CVE.

Imagine the amount of dependencies that use curl or the Linux kernel etc. These sweet innocent proposal makers thought in the terms of 5-10 dependencies per CVE. Not tens or hundreds of thousands which is far from unthinkable.

Recording (https://www.youtube.com/watch?v=O8Q8nIzEG6c ) and slides (https://static.sched.com/hosted_files/osseu2025/b3/pdx86-community-health-2025.pdf ) from Hans de Goede's #OSSEU25 talk "Creating a Healthy Vibrant [#Linux] #Kernel Subsystem Community" are now online.

From the abstract: "End 2020 I became the maintainer of the drivers/platform/x86 (pdx86) kernel subsytem. The subject of this talk is my experience in creating a friendly welcoming environment, growing the pdx86 community and how this helped me to avoid burnout by being able to delegate to community members."

https://osseu2025.sched.com/event/25VmE/creating-a-healthy-vibrant-kernel-subsystem-community-hans-de-goede-red-hat #LinuxKernel

The video of my presentation at OSSummit Europe is now available. 🇳🇱🐧

Those were 180 slides in 40 mins. 🫣😁 I hope people find it useful. Thanks! 🙂

Abstract & slides in the comments.

Linux Kernel Self-Protection Project 🐧🛡⚔️
#OSSummit #Linux #OpenSource

https://www.youtube.com/watch?v=nz0GId_zsIk

Suggestion for the week-end: Open Source Summit Europe 2025 video binge watching.

The Linux Foundation has just released all the videos they took at the OSS EU 2025 conference in Amsterdam. They are so many of them that they are hard to count!

https://www.youtube.com/watch?v=IGDWXA32xG4&list=PLbzoR-pLrL6qKwLt8A787ggMLHNivOHve

So, now you can attend OSS EU 2025 and the Embedded Linux Conference Europe 2025 free of charge, or if you attended, you can watch the many interesting talks that you missed.

Thanks to Ross Burton for sharing the news!

our community have always tried to embrace the upstream-first approach to development, and one of the largest roadblocks in that respect is often the Linux Kernel itself.

For better or worse it takes quite a lot of effort to get devicetree files and drivers upstreamed, but this is by far one of the more important goals for wider Linux Mobile adoption: upstream support makes devices more visible and encourages kernel maintainers to take more of an interest in the work we do

with that in mind, we are proposing an adjustment to the community device category requirements: to get your device into the community category it would now HAVE to have a devicetree in upstream, more specifically the upstream kernel needs to boot with some kind of display output and a working USB port - the bare minimum for easy tinkering, testing, and further development.

We hope that this will encourage device maintainers to get involved in upstream kernel development and submit their work rather than keeping everything in a kernel fork that they maintain

We are very open to feedback on this, please let us know what you think in the GitLab issue

https://gitlab.postmarketos.org/postmarketOS/postmarketos/-/issues/116

#LinuxMobile #postmarketOS #linux #kernel

nice https://reviews.freebsd.org/differential/changeset/?ref=1420532

Urgent help for OpenPrinting needed!

As many here know, I am co-founder and lead of OpenPrinting since 2001, known as the print guru for Linux and free software by many. I also got one of the 8 fellows of the Linux Foundation for this.

Up to now I was working at Canonical, hired back in 2006 just to run OpenPrinting and also to maintain printing-related Ubuntu packages.

... 🧵

Please boost.

#OpenPrinting #LinuxFoundation #getfedihired

Looks like the risc-v community is learning from history! Hopefully this results in more upstream development efforts: https://riscv.org/blog/2025/07/risc-v-upstreaming/

Saving this here to use later. As seen in the comments on yet-another-ai story on Lobsters:

"How could you claim to have a neutral, informed opinion on LLMs without signing up for a bunch of subscriptions and constantly talking to the liar machine to see if it told a truth today?"

One of my fav quotes from this @gregkh interview:

"Open source ends up having better depth of knowledge than closed source has."

(Because for careers in companies you get shifted around while many people in OSS stay in the same field/code for decades.)

https://www.youtube.com/watch?v=-1-OjxPJZcs

Linux Kernel Hardening: Ten Years Deep

Talk by @kees about the relevance of various Linux kernel vulnerability classes and the mitigations that address them.

Video: https://www.youtube.com/watch?v=c_NxzSRG50g
Slides: https://static.sched.com/hosted_files/lssna2025/9f/KSPP%20Ten%20Years%20Deep.pdf

All the slides at this meeting talk about how much time and effort "AI" would help us save, and all I want to do is point out how much time and effort I've sunk so far into keeping AI crawlers from DDoS'ing our infra.

Days since an "AI found security bug" turned out to be totally false due to the inability of the tool to actually parse C code: 0

I'm seeing multiple of these type of "reports" per week now for Linux. Why do people think that an LLM can somehow do better than a compiler and also not even test their proposed changes to verify they even do anything?

{sigh}

The second hardest thing in working in an open source developer community is learning who to ignore, be it in patch reviews or other places.

The hardest thing in working in an open source community is realizing that you are the one that everyone is ignoring.

Dear lazyweb. One of my nitrokey 3 devices seems to have “stopped working” when attempting to access the key in it. Running the command line tools seems to say all is good (i.e. nitrocpy nk3 test says all is fine) but yet ssh seems to hate it with an error of:

ssh_sk_sign: fido_dev_get_assert: FIDO_ERR_NO_CREDENTIALS

and it never even attempts to let me “push the button”.

It’s running the latest firmware. Any hints on what to attempt/test to debug this or should I just give up on the thing?

My backup key is working just fine, so it’s not the USB kernel code on my system that is the issue for once :)

Yet another thing I never thought I would be doing as a kernel developer, talking about EU regulations with open source finance people...

341 of the 733 changes[1] picked up for #Linux 6.15.3 could theoretically have made it into #kernel 6.15-rc6[2], as they were committed to some subsystem tree by then already.

Those are the changes that @gregkh meant when he recently wrote "[…] might also spur maintainers/developers to get fixes into -final a bit more as well :)"[3] (screenshotted).

[1] https://lore.kernel.org/all/2025061942-premiere-surreal-fa53@gregkh/

[2] And thus could have seen two weeks of testing before 6.15 was released – instead of about 3 days that 6.15.3-rc1 was out.

[3] https://lore.kernel.org/all/2025061030-latticed-capacity-dc94@gregkh/

#LinuxKernel