I've been playing with the LLM code assistants, trying to stress them out with the Linux kernel code. So far, I've had success with them writing reasonable unit tests:
https://lore.kernel.org/lkml/20250717085156.work.363-kees@kernel.org/
https://lore.kernel.org/lkml/20250724030233.work.486-kees@kernel.org/
These both saved me some time since it emitted quite a lot of good boundary testing code, but I had to massage them both a bit until I was happy with the coverage. But it was a net win on time spent.

And then I walked it through fixing a buffer overflow. This one didn't save me any time because I had to tell it how to look at the problem. Since it was a shorter/simpler session, I included my exact prompts just for anyone interested in what I did:
https://lore.kernel.org/lkml/20250724080756.work.741-kees@kernel.org/

This graph is the one I'm most excited about: the lifetime of security flaws in Linux is finally starting to get shorter (and the number of fixed flaws continues to rise).

https://hachyderm.io/@LinuxSecSummit@social.kernel.org/114750428620118674

Recently, I was debugging some intermittent boot failures and discovered that, on x86, forgetting to synchronize kernel page tables when installing new PGD entries can lead to kernel crashes.

Most of the time, PGD entries are populated during the boot process, and new tasks inherit page tables derived from the swapper process, so everything works fine.

However, if you're adding memory at runtime via memory hotplugging and populating new PGD entries for the vmemmap (i.e., the struct page array) and the direct mapping area, you need to iterate over all page tables in the system and update them accordingly to make it visible to all tasks.

Failing to handle this properly can lead to a situation where you think the page tables are set up correctly, but in reality, only init_mm.pgd (page table of the swapper process) was updated, not the page table of current task. This leads to kernel crashes since the PGD entry is not set up properly.

x86 code has mechanisms to handle this kind of synchronization, but it’s easy to be overlooked and introduce kernel crashes as the code evolves. Here’s my patch series that addresses the issue and aims to make it more robust: https://lore.kernel.org/linux-mm/20250709131657.5660-1-harry.yoo@oracle.com/

GNU Butt

It took a long time and over 60 articles but, at @lwn, we have finally managed to complete our reporting from the 2025 Linux Storage, Filesystem, Memory Management, and BPF Summit. If you want to know what is going on in those core parts of the kernel, this is the place to look.

We've put together an EPUB version of the whole set as well — good bedtime reading!

https://lwn.net/Articles/1026338/

In case you want to join my company (#SUSE), we're looking for an #infrastructure engineer!
#FediHire
https://suse.wd3.myworkdayjobs.com/Jobsatsuse/job/Czech-Republic-EMEA/Senior-Software-Engineer--Core-Platforms-_71006946

How does the kernel manage LRU lists and perform memory reclaim when memory cgroup feature is enabled? I wrote an article to answer that question.

Memory Cgroup Naturalization in the Linux Kernel v3.3
https://vmscan.org/memory-cgroup-naturalization-in-the-linux-kernel-v33

In the early days, memory cgroup was “bolted onto” the memory management subsystem, using a double-LRU scheme: each page was linked to both global and per-memcg lists—leading to a moderate memory overhead and complicating reclaim logic.

Linux v3.3 changed that. Memory cgroups were fully integrated into the MM core, global LRU lists were removed on memcg-enabled systems, and global reclaim began walking memcg hierarchy and scanning the per-memcg LRU lists, scanning each group in proportion to its memory usage.

This reduced memory overhead and simplified the reclaim code. More details in the article!

Linux 6.15 Released With Continued Rust Integration, Bcachefs Stabilizing

As anticipated the Linux 6.15 kernel is out today in stable form. Linux 6.15 brings a lot of new hardware support, security improvements, various other kernel innovations, and more...
https://www.phoronix.com/news/Linux-6.15-Released

i hope the nvidia driver doesn't crash

then: "when I grow up I'll be programming computers"
now: "i vibepirated code i wrote"

花桃の里の空に昇る天の川🌸🌌✨

#tokyocameraclub #東京カメラ部 #japan #花桃の里

Recently started learning how memory cgroup in the Linux kernel works, so started writing articles about it. The first posting for my English blog vmscan.org!

A brief look at memory cgroup controller introduced in the Linux kernel v2.6.25.
https://vmscan.org/a-brief-look-at-memory-cgroup-controller-introduced-in-linux-kernel-v2625

I have been spending seven hours every Saturday studying the Linux kernel with a study group for years. It's been fun, but over time, I started to feel like I wasn’t spending my time wisely. I have to accept the fact that I don’t have enough time to regularly look at anything outside of MM.

I tried GPT-o3 (which uses 'advanced reasoning') to review slab patches to see if it works, and it generated many false comments. :P Less advanced than I expected.

Spot on advice for any field.

For gym motivation is useless, it's all discipline, your test is on a day when you 100% hate it and want to do ANYTHING ELSE.

Music is my hobby but barely done any, because it is work really, a different kind, but if you want to get anywhere with it, you have to have the same discipline.

But I plan to apply the same gym-like discipline to that to get what I want out of it.

And of course this goes for kernel work too, obviously.

https://www.youtube.com/watch?v=4pw1tmGh3dk

Blogging time after a long time.
/me again realizes that things not documented are quickly reclaimed from memory.

Oh, I didn't know a CVE can be assigned to my bug fix without me requesting or realizing it. I thought (despite not being a security expert) it was not a 'fun' bug to exploit for attackers.

https://nvd.nist.gov/vuln/detail/CVE-2025-21860

Well well, look what the cat dragged in
https://nostarch.com/linux-memory-manager

Very happy to announce my book The Linux Memory Manager is now available to pre-order at

https://nostarch.com/linux-memory-manager

It's a comprehensive 1,300 page exploration of how memory functions in Linux that goes into great depth on the subject, and is the first book of its kind for 20 years :)