Calibrating your fear of big bad optimizing compilers

Posted Oct 11, 2019 21:30 UTC (Fri) by scientes (guest, #83068)
Parent article: Calibrating your fear of big bad optimizing compilers

The C++ memory model atomics are way easier to use than these kernel macros that predate them and use volatile. Using volatile like this, now that atomics exists, is code smell, IMHO. I am not sure if C exposes them, but it should.

https://www.llvm.org/docs/Atomics.html

Calibrating your fear of big bad optimizing compilers

Posted Oct 11, 2019 21:58 UTC (Fri) by scientes (guest, #83068) [Link]

Nevermind.

Calibrating your fear of big bad optimizing compilers

Posted Oct 12, 2019 9:17 UTC (Sat) by hsivonen (subscriber, #91034) [Link] (3 responses)

Atomics require the other thread of execution to be conforming to the C++1/C11 memory model. There is no such guarantee for userland processes, so using atomics to access userland memory from the kernel is technically UB.

The only thing in C or C++ that allows you to access (in a non-UB way) memory that doesn’t participate in the memory model is volatile, but since the use case it is designed for is memory-mapped devices, it inhibits more optimizations than would be necessary for the use cases of kernel accessing userland memory when responding to a syscall, a hypervisor accessing guest memory when implementing a virtual device, or a Wasm host assessing a SharedArrayBuffer Wasm heap when responing to a call to a host service.

Considering that this type of software is typically implemented in languages that inherit the C++11 memory model (C++ itself plus C11 and Rust), it’s surprising that this facility is missing.

Calibrating your fear of big bad optimizing compilers

Posted Oct 12, 2019 16:03 UTC (Sat) by scientes (guest, #83068) [Link] (2 responses)

>so using atomics to access userland memory from the kernel is technically UB.

But don't we only look at user-land data from the same thread that sent the data, so there are no races (and we don't trust the data, so if another thread with access to that data changes it, that is their problem.)

Calibrating your fear of big bad optimizing compilers

Posted Oct 12, 2019 16:47 UTC (Sat) by excors (subscriber, #95769) [Link] (1 responses)

> (and we don't trust the data, so if another thread with access to that data changes it, that is their problem.)

If the access from the kernel is undefined behaviour (because another user thread modified that memory in violation of the rules), that's the kernel's problem. Undefined behaviour doesn't just mean the kernel will read an incorrect value, it means absolutely anything could happen (and would happen with kernel privileges).

Calibrating your fear of big bad optimizing compilers

Posted Oct 12, 2019 19:12 UTC (Sat) by hsivonen (subscriber, #91034) [Link]

Right. The C++11/C11 memory model has just UB and doesn’t say which thread of execution experiences the UB. For use cases like kernel vs. userland, hypervisor vs. guest, Web browser UI vs. renderer, and Wasm host vs. Wasm program, you want to have things defined such that the more privileged side can’t experience UB if the less privileged side doesn’t follow the rules.

Calibrating your fear of big bad optimizing compilers

Posted Oct 15, 2019 13:37 UTC (Tue) by klempner (subscriber, #69940) [Link]

The one thing that jumps out is the invented load issue with #5, which is a problem that relaxed loads and stores don't have but apparently a STORE_ONCE/LOAD_ONCE pair do.