LWN: Comments on "Bringing restartable sequences out of the niche"

I missed something about abort

corbet — Sun, 24 Aug 2025 18:42:04 +0000

Yes, a system call can result in those things. As an extreme example, think of a read() call that has to wait for data to be brought in from disk; that will result in the calling thread losing access to the CPU indefinitely. But almost any system call can result in preemption and/or migration of the calling thread.

I missed something about abort

ssmith32 — Sun, 24 Aug 2025 18:02:46 +0000

Maybe more succinct: can a system call trigger what the retart code considers "an event" ( pre-emption, interrupt, cpu migration) ?

I assume the answer is "possibly", in which case the code loops infinitely. But wondering if I'm misunderstanding.

I missed something about abort

ssmith32 — Sun, 24 Aug 2025 17:57:57 +0000

So there's this:

"the kernel will handle a system-call return in the same way as an interrupt return: if the thread is running in a critical section and an event has occurred, control will be redirected to the abort handler. "

And this:

" If the current instruction pointer lies within the critical section, the kernel will cause execution to jump to the abort address. The thread can then clean up after its aborted attempt and restart the operation. "

What's "if an event occurred"?

I read this as saying invoking a system call in a critical section results in the abort handler being called.. which restart the sequence, which would seem to be a bit (infinite) loopy.

But the rest of the article seems to imply the current (pre-tglx) code inadvertently works on non-debug kernels.

So I missed something, probably obvious.. but I can't sort out what.

Followup series

corbet — Sat, 23 Aug 2025 18:42:45 +0000

For the curious: Thomas Gleixner has posted a followup series fixing another set of problems and offering some strong commentary on the situation as a whole.

If this threatens a userspace (meaning glibc in particular) change ...

comex — Sat, 23 Aug 2025 01:42:49 +0000

macOS does do runtime checks based on compatibility versions, but it also does something more sophisticated.

There's a compiler flag to specify the minimum OS version you need to run on. Meanwhile, every declaration in every system header is marked with a minimum OS version, so you get an error if you accidentally use a newer function (this can be disabled for functionality you want to use conditionally). In more subtle cases, header files can manually check the target version with #if and change their behavior, though this is rarely done.

The goal is that you can always use the latest SDK, even if you are targeting an old OS version (though there is a limit to how far back you can go).

I think glibc would be well-served if it adopted a similar scheme.

Please Rewrite Glibc RWlock or Revert to Drepper's Good Old Implementation.

PengZheng — Fri, 22 Aug 2025 03:02:55 +0000

> Mathieu Desnoyers (the creator of this feature) has been advocating for increased use of it within glibc to improve scalability for some time.

I would once again propose the buggy rwlock([1]), which is a complicated mess, as a rewrite candidate.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=31477

If this threatens a userspace (meaning glibc in particular) change ...

quotemstr — Fri, 22 Aug 2025 00:43:12 +0000

People look to glibc for inspiration on how to use symbol versions in general, and what glibc does is wrong and broken. And no, "just compile on an old docker image" isn't a solution either: what if I want to write a program that *conditionally* uses new functionality? If I compile against old glibc headers, I don't see definitions of the new functionality. If I compile against new glibc headers, I can't run on older systems. The whole situation sucks. The whole problem is avoided by simply not overloading function by version.

How do you solve the problem of shipping bugfixes that might break older versions e.g. the infamous memcpy direction problem? Use what macOS, Windows, and Android do: compatibility versions embedded in the binary manifest.

If this threatens a userspace (meaning glibc in particular) change ...

intelfx — Fri, 22 Aug 2025 00:29:57 +0000

> glibc refuses to provide a preprocessor macro for targeting older systems

Perhaps this is a glibc problem rather than a symbol versioning problem?

If this threatens a userspace (meaning glibc in particular) change ...

quotemstr — Fri, 22 Aug 2025 00:17:27 +0000

I wish people wouldn't use ELF symbol versioning. It causes problems the moment you step off of the narrow path of running old binaries AOT-compiled native-code on new systems.

What happens if you call dlsym? What happens if you try to build a program on a new system targeting an old one and pick up the new symbol without realizing it? (glibc refuses to provide a preprocessor macro for targeting older systems.)

Much better to give new functions new names. Don't add a symbol version my_api@2. Just define a my_api2(). It looks uglier in the short term, sure, but saves everyone trouble in the end.

If this threatens a userspace (meaning glibc in particular) change ...

davecb — Thu, 21 Aug 2025 16:43:33 +0000

... glibc is one of the Linux users of versioned interfaces.

Ask them how to support an abi change by versioning the interface that changed, using linker symbols. High-level (and oversimplified!) view in https://leaflessca.wordpress.com/2018/05/31/an-alternativ..., and the real details in David J Brown's proposal, https://www.usenix.org/legacy/publications/library/procee...