LWN.net comments

Thoughts from a younger generation..

malmedal — Mon, 18 May 2026 20:29:21 +0000

What's actually been happening lately is that the LLMs have been instructed to ask the humans clarifying questions when instructions are ambiguous.

Thoughts from a younger generation..

Wol — Mon, 18 May 2026 19:18:07 +0000

> Perhaps ultimately we will end up formulating technical specification languages, to help humans precisely communicate the requirements to the LLMs. And then the humans can get LLMs to help them prepare the specifications in such technical specification languages, for other LLMs to implement... And...

Don't we have things like that already? It's just that currently they're called compilers, not LLMs ...

Cheers,
Wol

Thoughts from a younger generation..

mb — Mon, 18 May 2026 17:05:23 +0000

Yes, LLMs make mistakes.

But things like that are typically a result of not doing a proper development cycle.
Code generation (code writing) is not a full cycle.

Proper development, both human and AI, require things like:
- Requirements review
- Design review
- Code review
- Failure mode analysis
- Development of coding guidelines
- Coding
- etc...

If you just use an LLM to do the coding step and then say you are done, you leave out the most important steps.

Things like /* Follow RFC xxxx Section yyyy */ and the code doing something different are actually not that hard to find with AI tooling.

If a proper development cycle is used, then AI generated code can be quite good. Much better than hand-coded code from most developers.

Thoughts from a younger generation..

jpeisach — Mon, 18 May 2026 16:17:22 +0000

> And in the marvelous future ahead of us, we'll get to do all this, except with LLMs, and we can get rid of that horribly boring bit - the actual software development! Yay! And it'll be all be so much more efficient!

And I'm sure it will be worth the time, effort, electricity, water, and energy to do all the training and LLM directing instead of just manually coding it.

Thoughts from a younger generation..

paulj — Mon, 18 May 2026 16:05:29 +0000

Oh, and we won't have to worry about verifying that the LLMs actually produced code that matched the spec, cause as we all know, LLMs are incredibly good at following specifications and prompts /exactly/, and never invent stuff.

The future looks so bright!

Ownership

daroc — Mon, 18 May 2026 16:02:51 +0000

I wasn't present for that talk, but as I understand it, this is the point of flushing the TLB when the page tables change: either the other process accesses the page before the TLB is flushed (and the address is present in the TLB), and the access succeeds, or it accesses the page after the TLB is flushed, and has to walk the page tables. The updated page tables will show that the area isn't mapped, and the process will get a segmentation fault, just as it would for any other inaccessible memory. If application authors don't want to get segmentation faults, they should ensure their programs don't do that, using whatever technique they'd like (locking, static verification, etc.).

Thoughts from a younger generation..

paulj — Mon, 18 May 2026 15:58:56 +0000

The LLM operators will have to become experts in carefully specifying the functionality they want the LLM to implement. Perhaps ultimately we will end up formulating technical specification languages, to help humans precisely communicate the requirements to the LLMs. And then the humans can get LLMs to help them prepare the specifications in such technical specification languages, for other LLMs to implement... And...

Basically, "programming" is going to be like the requirements gathering phase of software development today. The phase where, *today*, someone meets with {internal,external} clients / "stakeholders" and brainstorms or walks through exactly what they want from the product, goes away and puts that in documents (technical documents, storyboards, mock-ups, etc.), then goes back and meets them again to refine, and so on - to ultimately produce something to give to the developers to implement. Who will read the documents and point out all the problems (inconsistencies, impossibilities, etc.), and the person has to go back to the clients/stakeholders and refine further. Etc., etc.

That person is sometimes called a product manager. And that portion of software development is universally considered the _really fun_ part of the job.

And in the marvelous future ahead of us, we'll get to do all this, except with LLMs, and we can get rid of that horribly boring bit - the actual software development! Yay! And it'll be all be so much more efficient!

Thoughts from a younger generation..

bertschingert — Mon, 18 May 2026 15:53:25 +0000

I feel like I have the opposite experience working with LLM generated code. The fact that it's perfectly formatted and follows conventions / best practices to a T means that it isn't always "messy... and miserable to work with". I've actually found it to be easier to read than code written by a junior developer.

The issue is that it definitely isn't "probably... correct". Hallucinations are still very much an issue. Just the other day I reviewed an LLM written codebase that implemented a specified protocol. There was a point in the code that blatantly violated the spec... right beneath a comment that said

> /* Follow RFC xxxx Section yyyy */

and then it did something that was trivially and obviously wrong with respect to that section of the RFC.

So my experience is that LLM written code is actually quite readable and nice to work with. It just might happen to be completely wrong.

Thoughts from a younger generation..

jpeisach — Mon, 18 May 2026 15:26:28 +0000

> When people don't bother learning to write software, they eventually won't be able to check the output of LLM code generators, and then we'll be in real trouble.

Well, the LLM code generators will probably be correct, it's just going to be code that is messy, slow, and miserable to work with.

Now to test the tests

neggles — Mon, 18 May 2026 15:25:52 +0000

An object is empty-initialized if it is explicitly initialized from initializer = {}. (since C23)

In some cases, an object is empty-initialized if it is not initialized explicitly, that is:

- pointers are initialized to null pointer values of their types

...

Seem's it's "whatever null is", so doesn't have to be bitwise zero

Thoughts from a younger generation..

dskoll — Mon, 18 May 2026 14:45:00 +0000

We don't even code anymore, we get the energy-hungry, brute-force machines to do that.

This is going to be a huge problem. When people don't bother learning to write software, they eventually won't be able to check the output of LLM code generators, and then we'll be in real trouble.

Thoughts from a younger generation..

paulj — Mon, 18 May 2026 13:30:15 +0000

The "brains" of computer science today are spent optimising overwhelming-brute-force algorithms, which are pretty much impervious to any kind of mathematical analysis. So.. not much scope for maths there.

And generally, everything in computers now revolves around applying ever greater brute-force. Collectively, we appear to have decided to stop solving problems directly, but instead we apply said massive brute-force. We don't even code anymore, we get the energy-hungry, brute-force machines to do that.

Another of the great old ones passes

nix — Mon, 18 May 2026 13:19:06 +0000

Oh no :( :( :( one of the old immortal greats, and perhaps one of the best list moderators ever. But it turns out that nobody is immortal after all.

Thoughts from a younger generation..

dvrabel — Mon, 18 May 2026 13:10:56 +0000

Trying dividing people into computer scientists (maths/theoretical), software engineers (design/process), and programmers (craftspeople), then I suspect the absolute number of computer scientists continues to grow at a slow rate, whereas the number of programmers increases at a ludicrous rate, skewing their percentage share in their favour.

Ownership

claudex — Mon, 18 May 2026 13:05:01 +0000

> when that process exits or closes the file descriptor, the region disappears and mappings in other processes are removed.

What happen if another process is accessing the region while the owner process close it ? And does it mean that the non owner process should make a check that the region is still existing before each access (with some kind of lock?) ?

off-by-ten?

corbet — Mon, 18 May 2026 13:02:53 +0000

Typo fixed. Meanwhile, as noted right above the comment box, please send typo reports via email rather than posting a comment to a four-year-old article.

Thoughts from a younger generation..

jpeisach — Mon, 18 May 2026 12:18:51 +0000

First of all, rest in piece. He will be missed.

Second, as time goes on, the greats of Computer Science will continue to pass away. This leads to the people of today - of which, who will be the successor?

I may be looking at things from the wrong perspective, but I worry about this and a general "loss of knowledge". When I think of "Computer Science" today, the first thing that comes to mind is everyone using web development frameworks, like React, which feel like all anyone can talk about. It feels that we are slowly drifting away from the original math, thinking, and *science* that makes up Computer Science. We're losing the people who launched this field, and I don't know the replacements, nor if they really are, the future of computer science. People who really know what they are doing. People who think and reason, instead of just doing whatever.

I don't know if I'm making sense, but does anyone else feel like this?

Status of recent 0-days?

arekm — Mon, 18 May 2026 09:55:13 +0000

Fragnesia stuff still being worked on.

off-by-ten?

andy_shev — Mon, 18 May 2026 09:19:44 +0000

1998 or 1988 developers in v5.16?

Status of recent 0-days?

NightMonkey — Sun, 17 May 2026 20:29:11 +0000

Any movement in this release on the recent 0-days? :)

Mark authencesn as BROKEN?

DemiMarie — Sun, 17 May 2026 01:02:11 +0000

That could be an option.

Fragnesia

iabervon — Sat, 16 May 2026 13:59:45 +0000

Personally, I'm not going to be confident in anything being safe if it uses authencesn and that hasn't been made to follow the behavior of the other AEAD algorithms. It's too hard to be sure there's no remaining way to make that do the wrong thing, even if people haven't found a new one for a few days.

Great product

greatquux — Sat, 16 May 2026 13:42:11 +0000

Hear hear! I have been using it for years. One thing that held me back was that I listed to a lot of live tracks and the gapless support in GStreamer for MP3 especially was always "incomplete" in a way that required the application to support it. It's finally been working in last few releases so I no longer need to use Audacious just for live tracks and Strawberry for organization.

Fragnesia mitigations

tim_small — Sat, 16 May 2026 06:57:27 +0000

No, but for the vast majority of hosts which don't use IPSec, you can prevent the esp4 and esp6 kernel modules from loading, e.g. as detailed in https://ubuntu.com/blog/fragnesia-linux-vulnerability-fix...

Fragnesia

AdamW — Sat, 16 May 2026 06:42:41 +0000

Bits of it are...

People keep finding new paths to hit essentially the same thing, so saying whether it's "fixed" or not gets complex. Fedora's 7.0.8 build also includes "- net: skbuff: propagate shared-frag marker through frag-transfer helpers (Hyunwoo Kim)" which I believe fixes the most recently-disclosed paths.

BPF mm stability

RazeLighter777 — Sat, 16 May 2026 02:33:25 +0000

It's interesting examining the problem of supporting stability for BPF, the docs technically do make some ABI claims about for instance about kfuncs being potentially subject to change while BPF helpers are not and are considered stable.

It's difficult to reason about verifying a program for memory management in BPF. It seems unlikely that on the first try we'd get something flexible enough for all use cases, yet that doesn't fundamentally break the "safety" provided by the verifier. So I see why this has been a thorny topic.

Fragnesia

arekm — Sat, 16 May 2026 01:36:40 +0000

But Fragnesia not fixed, right?

Mitigation

mowsey — Sat, 16 May 2026 00:53:13 +0000

Agreed.

"unshare -U -r" is enough to break kernel.yama.ptrace_scope = 2

I'm not sure why the POC doesn't work, but gdb definitely does, so the POC should.

One could also disable unprivileged user namespaces, kernel.unprivileged_userns_clone = 0 as you say, which might be a good option if one wanted to keep root debugging, but its becoming more complicated advice.

Probably "set kernel.yama.ptrace_scope = 3 and reboot once you have a patched kernel" is the simpler advice. :-)

People should be paying attention to the role of splice in these bugs.

azz — Fri, 15 May 2026 22:07:48 +0000

> However doing this as a config option won't work: distros will need to keep it enabled due to the numerous users.

That depends on the distro. For hardening an embedded device, where you really don't want to be doing frequent kernel updates if you can avoid it, turning off kernel features that your application doesn't need is good hardening practice - and I'd imagine there are a decent number of embedded applications that could live without splice and friends (and ptrace and friends, for that matter).

What are we gaining with chat?

dskoll — Fri, 15 May 2026 21:56:25 +0000

I agree. Chat programs are OK for casual, unimportant conversations. But I would never do anything important via chat without subsequently sending a summary email to everyone so there's a record.

IMO, we should treat chats the same as casual conversations: If anything important comes up that needs followup, we make a memo or an email to record it.

Mitigation

cypherpunks2 — Fri, 15 May 2026 21:53:30 +0000

kernel.yama.ptrace_scope = 2 does not protect against it even if it breaks the PoC. The vulnerable code can be reached using unprivileged user namespaces even if ptrace itself is blocked. The only mitigations are kernel.yama.ptrace_scope = 3 which breaks debugging even by root, or kernel.yama.ptrace_scope = 2 along with kernel.unprivileged_userns_clone = 0 which doesn't break debugging but breaks unprivileged user namespaces (arguably a good thing in general, this bug aside).

Mitigation

mowsey — Fri, 15 May 2026 21:09:49 +0000

Here is a working mitigation, but it disables ptrace (debugging) until the next reboot:

echo 3 > /proc/sys/kernel/yama/ptrace_scope

This prevents the bug from being exploited, but also prevents debugging, even by root.

Here is one that works against the released POCs and still allows root to debug, but maybe I don't know modern container escapes, and it also allows non-root to exploit the bug:

echo 2 > /proc/sys/kernel/yama/ptrace_scope

I tested a simple container with "unshare -U -r" which made it look like I had ptrace capability, but did not, and the exploit failed.

The only advice I found for mitigation was either custom (kernel.ptrace = 0) or wrong (kernel.yama.ptrace_scope = 1). I confirm the exploit reads private ssh keys in under a second with kernel.yama.ptrace_scope = 1, but cannot when = 2 or =3.

Not all distributions have patched kernels yet, and it sure has been a lot of reboots this week, so maybe this will give a little time to catch up.

What are we gaining with chat?

tbuskey — Fri, 15 May 2026 20:59:31 +0000

We had many very good ways to archive/thread/index/filter/block NNTP and mailing lists. Even across several newsgroups. The same tools often worked across both. Delivery was asynchronous and fast enough for most cases. If it wasn't, you had the telephone to fall back on.

I can find things I wrote in the 90s pretty easily. I have a hard time finding anything in Slack from even a month ago. I don't think IRC or any of the other chat tools are much better. No one minds chat as much as we didn't like phones

Rationale for the pseudo-random threshold?

zachmu — Fri, 15 May 2026 19:33:21 +0000

The threshold is a response to this problem in the original chunking algorithm. We found that a simple rolling probabilistic hash produces a geometric distribution of chunk sizes, with many very large chunks in the tail end of the distribution. This killed write performance.

We wrote about it here:

https://www.dolthub.com/blog/2022-06-27-prolly-chunker/

Is that not the LLM guy?

cypherpunks2 — Fri, 15 May 2026 19:07:22 +0000

> but to operate a Torment Nexus is the sort of thing even I was able to do…

To be clear, I didn't mean that I used an LLM. I meant that it was something that I, at the time new to kernel development, could do on my own without "vibe coding". Thus if a newbie could do it without an LLM, surely an expert with an LLM could do it just fine without running into the usual slop problems that happen when you ask one "make a patch that does $ill_defined_vaguely_worded_thing kthx".

The nice thing about neural networks is that, once the hardware is built, the only continuous resource they require is power, and power can be supplied by renewable energy. After the AI bubble bursts, I suspect many of the surviving companies that were previously disregarding ethics in favor of aggressive competition will start switching to renewable energy in order to get contracts from companies that want "green" resources.

Dolt contains no MySQL code

zachmu — Fri, 15 May 2026 19:00:39 +0000

Nice article, but a small correction: Dolt is not a fork of MySQL and contains no MySQL code. It's a completely new implementation from the ground up, both the storage layer and query engine. Similarly, Doltgres is not a fork of Postgres and contains no Postgres code. The query engine for both databases is go-mysql-server, and they both use storage and version control libraries implemented in the Dolt project.

DoltLite is different: it's a fork of SQLite3 with the storage engine ripped out and replaced with a prolly tree implementation.

There's also a fourth variant that's even newer: DumboDB. It implements the dolt version control operations in a Mongo-compatible document database. Like Dolt and Doltgres, it contains no mongo code. It's a new implementation.

Dolt's implementation of prolly trees did indeed originate with Boodman's noms project, but similar concepts in other domains date back to at least 2009 by our research and there are probably even older ones. Like many inventions, prolly trees have a long history with many contributors, and people continue to re-invent the concept independently. See this blog for more background.

Open registration

jzb — Fri, 15 May 2026 18:36:08 +0000

Since it was ambiguous, I asked the Forgejo folks to clarify what was meant here. I received this reply, which said, "It requires either admin credentials or an internal access token that Forgejo uses to communicate with itself in some situations."

Stop here

jzb — Fri, 15 May 2026 18:31:40 +0000

This is a fine space to discuss the technical details of these bugs; but let's not make it personal. It is not necessary and not what our comment section is for.

Many use cases

bluca — Fri, 15 May 2026 18:22:52 +0000

This is very exciting work! The use cases go beyond just VMMs, for example this would be very beneficial to keep forwarding tables in memory across reboots when using software dataplanes

People should be paying attention to the role of splice in these bugs.

koverstreet — Fri, 15 May 2026 18:18:28 +0000

Matthew, everything I said was factually correct. It's right there in the code.

We've got zero-days coming out once per week, people are rushing to keep everything patched and evaluating how to mitigate, and you're lashing out and deflecting. I've seen you do it to other people too.

This does not bode well.

Everyone's code, my own included, has issues. I quite regularly have to communicate to people the state things are in and what they can expect. You don't have to take it as an attack.

LLMs don’t respect anything either

cypherpunks2 — Fri, 15 May 2026 17:54:04 +0000

If you presuppose that LLMs are evil, then of course you won't be able to understand why someone might reference "responsible use of LLMs" when after all there's no such thing as responsible use of evil. But they are not fundamentally evil, no more than the transistor is at least.

There is a lot wrong with the use of LLMs and the companies behind many popular LLMs that is valid to criticize but it seems like you're against the technology itself. There's no need to bring things like racism or exploitation (which one could say is associated with <i>any</i> computer technology) when there are valid criticisms of its use.

Neural networks (of which LLMs are a subset) have a great amount of good use. They can simulate protein confirmations with high accuracy and can be used for improving medication and curing disease. They can be used to detect cancer by analyzing medical images. They can scan PRs to find vulnerabilities before they get merged that would otherwise be exploited by genuinely evil state actors (NSA, GRU etc). They can assist people speaking underrepresented languages to communicate better with other cultures.

But they can also be used to trick people into forming parasocial relationships. They can be used to spread customized misinformation. They can be used to target people for military strikes or for surveillance. They can be used to flood art sites with regurgitated low-effort slop. And of course in their insatiable need for information, they can DDoS websites with their spiders as they try to find new training material. But "assist in generating a patch and review it" is not evil. It's responsible, depending on the quality (and ease of maintainability) of the patch itself.

Pardon the naive question...

cypherpunks2 — Fri, 15 May 2026 17:42:51 +0000

In that case I wouldn't say that using an IDS would detect this exploit or it'll create a false sense of security. It would be better just to say that you might be able to catch a sloppy script kiddie using an IDS but that you shouldn't rely on it as a detection mechanism. Just imagine someone in 2018 asking "how do I find out if someone used the DirtyCoW exploit on my system?" and someone else replied "normally one uses history | less to detect this".

People should be paying attention to the role of splice in these bugs.

willy — Fri, 15 May 2026 17:26:18 +0000

I don't owe you anything.

I'm not engaging with you. I'm just letting everybody else know that you're lying.

Internal fragmentation

anton — Fri, 15 May 2026 17:24:27 +0000

I made some measurements of how much internal fragmentation would grow with various page sizes and posted it on Usenet <2020Oct9.190337@mips.complang.tuwien.ac.at> Given that I no longer know a working Usenet archive, I just repost this work here:

I use the following script:

cat /proc/[1-9]*/maps|
awk '$2~/.w.p/||!$2":"$6 in m {m[$2":"$6]=1; print $1" swap - doit"}'|
sed 's/-/ /'|
gforth -e 'variable mem create ps $2000 , $4000 , $8000 , $10000 , create sums 0 , 0 , 0 , 0 , : doit 4 0 do dup ps i th @ naligned over - sums i th +! loop mem +! ; hex stdin include-file decimal : printit mem @ $400 / 8 .r 4 0 do sums i th @ $400 / 8 .r loop ; printit cr bye'

On my desktop this outputs the second of the following lines:

 total       8KB    16KB    32KB    64KB
 1040972    6676   22244   56148  124788

The 8KB column tells how many extra KB would be used if the page size
was 8KB.  Comparing total memory as determined by this script to the
output of free (555900 without buffers/cache) indicates that, on
average, only about half of the address space in a VMA is consumes
memory; so there is also quite a bit of uncertainty about my estimates
for extra memory.

For the three machines above [desktop (2h uptime, spartan user interface);
 laptop (54d uptime, Ubuntu, Gnome, 2 users); server (89d uptime, Debian,
 Gitlab and Jitsi in Docker)], I get today (numbers in KB):

VMAs unique    used     total      8KB    16KB    32KB    64KB   
 7552  2333    555964  1033320    6704   22344   56344  125144 desktop
82836 25276   5346060 15707448   76072  223000  514472 1113672 laptop
47017 15425 105490636 60186068   40804  134492  319852  708588 server

I have no explanation why used is higher than total on the server.

If you want to get an average VMA size, just divide total by unique.

In any case, even with the considerable uncertainty from partially
populated VMAs, the extra cost of 8KB or 16KB pages does not appear to
be large, even on the laptop.

At current RAM prices, not everybody will want to spend an extra 1.1GB on 64KB pages for internal fragmentation, but having the option would be nice, and having some in-between option, too.

L1 TLBs are as small as they are because making them larger also means that they are slower, and at some point the L1 cache access speed is limited by TLB speed. For highly or fully associative structures (as is often the case for L1 TLBs), power consumption is also an issue.

People should be paying attention to the role of splice in these bugs.

koverstreet — Fri, 15 May 2026 14:10:04 +0000

> Tell me, has anyone looked at the interactions with large folios and splice?

To answer my own question, "yeouch". A lot of the obvious ones are awkwardly patched over in callers, but I expect this to be fruitful mining for security researchers.

Disabling CONFIG_TRANSPARENT_HUGEPAGE for the next six months might be smart.

People should be paying attention to the role of splice in these bugs.

koverstreet — Fri, 15 May 2026 13:04:14 +0000

Matthew, you don't take criticism well.

Back when you were getting folios merged, there were concerns raised by the mm community, primarily Johannes, and I argued vociferously for getting folios in because we needed it. But seeing how it's played out, he had a point.

I keep getting reports of nuttier and nuttier mm behavior - it's getting worse, not better, and there's not much I can do about it but attempt ugly workarounds, and I can't even work around the one you guys introduced in large folios where you forgot to include a range in .set_folio_dirty. Know what that does to mmap write workloads?

Tell me, has anyone looked at the interactions with large folios and splice?

Magnifying glass

marcH — Fri, 15 May 2026 12:13:39 +0000

Forgot to say, sorry.

> Just for fun, try to move people away from Instagram and to Mastodon.

I'm not claiming Mastodon is some perfect solution to it all. But:
- for sure it's trying hard
- Most people on Instagram and co. won't even want to _hear_ about it. That was my point.

Magnifying glass

marcH — Fri, 15 May 2026 12:06:46 +0000

> I don't understand this paragraph. You are welcoming the death of email and in the same breath bemoaning the things that all other modern forms of communication more naturally lend themselves to (echo chambering, etc.).

Yes, because they are both buggy by design. The former has no filtering. To "solve" that lack of filtering, you are the product in the latter. And what the dopamine drugs the attention merchants get us dependent on is so addictive and effective that we don't even look for alternatives. Just for fun, try to move people away from Instagram and to Mastodon.

The rest of your comment lost me, sorry.

Proprietary software enablement, not hardware

farnz — Fri, 15 May 2026 10:57:18 +0000

Yeah - that's kinda my point. When you strip this proposal down to the concrete actions that will be taken, it's just "we should enable people to use NVidia's proprietary userspace on Fedora", and nothing else - calling it "hardware enablement" isn't really accurate, either, because it's not just about enabling the use of NVidia hardware, but about enabling the use of NVidia's proprietary APIs, too.

I would feel very differently about it if it was (say) "we're going to make ZLUDA work on all the big Mesa Vulkan drivers so that you could use CUDA code on AMD, Intel or NVidia hardware", or even "we're going to support running ML models on NVidia proprietary Vulkan to the same extent they're supported on RADV and ANV". But instead, it's "well, NVidia's proprietary CUDA userspace is popular, so we should support that".

Seriously?

rwmj — Fri, 15 May 2026 07:56:32 +0000

This is a good argument for including the proprietary bits in RHEL. It doesn't seem to have much to do with Fedora however.