Re: racy acccess in kern_runq.c

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Andrew Doran <ad%netbsd.org@localhost> wrote:
> On Fri, Dec 06, 2019 at 10:27:20AM +0100, Maxime Villard wrote:
> 
> > With 'worker_ci', there is an actual safety issue, because the compiler
> > could split the accesses and the hardware may not use atomics by
> > default like x86. This could cause random page faults; so it needs to
> > be strictly atomic.
> 
> No I don't accept that.
> 
> The ability to load and store a native word sized int (and in more recent
> years a pointer) with a single instruction is a fundamental assumption
> that every operating system written in C rests upon.
> 
> If the compiler splits one of those acceses, then you are either using
> some other data type, or have a broken compiler on your hands.  If the
> compiler is broken it's the compiler you should be looking at, not the
> program it compiled.  It's as simple as that.

Compilers have became much more aggressive over the years.  But they are
allowed to be so by the C standard.  Specifically, in addition to code-level
re-ordering, plain accesses (loads/stores) are subject to load/store fusing,
tearing as well as invented loads/stores.  At least load/store fusing and
tearing *have* been observed in reality [1] [2] [3].  So, they are *not*
merely theoretical or esoteric problems, although there are plenty of these
in the C11 memory model too [4] [5].

Linux kernel developers went through this already.  Perhaps the C standard
will plug the holes or perhaps compilers will just change their behaviour,
as they get enough criticism [6] [7].  However, in the mean time, I think
let's just accept that things moved on and let's embrace the new primitives.
While these primitives might be slightly verbose, they are in C11, they fix
real bugs, they definitely make code less error-prone and they have other
merits too (e.g. they accommodate static analysers which find some real bugs).


[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a7b100953aa3
[2] https://lore.kernel.org/lkml/20190821103200.kpufwtviqhpbuv2n@willie-the-truck/
[3] https://www.mail-archive.com/linux-kernel%vger.kernel.org@localhost/msg2015622.html
[4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1797r0.html
[5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1756r0.pdf
[6] https://lwn.net/Articles/478657/
[7] https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01538.html

-- 
Mindaugas