From: Laurence Tratt <laurie@tratt.net>
Subject: Re: ip sysctl atomic
To: tech@openbsd.org
Date: Thu, 16 May 2024 13:00:12 +0100

On Thu, May 16, 2024 at 01:45:59PM GMT, Mark Kettenis wrote:

>> My worry then remains my worry now: modern versions of C have a largely
>> well-defined memory model, and a decent API for making use of it, but we
>> don't seem to be making use of it, which means that we're probably
>> exposed to various multi-threading problems, particularly on non-x86.
> https://lore.kernel.org/lkml/CAHk-=whY5A=S=bLwCFL=043DoR0TTgSDUmfPDx2rXhkk3KANPQ@mail.gmail.com/

Linux, as far as I can tell, has taken a different approach to OpenBSD.
OpenBSD's `READ_ONCE` for example does not use inline asm to block compiler
optimisations, instead relying on `volatile`, which does not guarantee
atomic access.

In that sense one could say that we are in danger of having the worst of
all worlds: we are not telling the compiler that it can't optimise things
and we are using a compiler (clang/LLVM) that can and does optimise such
things; and we are not generating code which tells the CPU to do the right
things either. The more that the kernel is unlocked, particularly on weak
memory model systems like Arm, the more this will lead to weird,
intermittent bugs.

Put another way: we can absolutely roll our own memory model with inline
asm, but it does take a lot of thought, care, and documentation. Given how
much effort has been put into modern C's memory model, and into the
compiler, I would personally rather stand on the shoulders of others, but
this is an opinion rather than a fact.

[Personally, I don't think Linus's implicit argument that "LLVM has a bug
in its optimiser for feature X therefore feature X is completely wrong" is
a strong one. Big compiler frameworks, like every other piece of software,
have lots of bugs in them. My personal experience is that this is not a
hugely buggy part of LLVM, at least compared to some other parts I know of.]


Laurie