Re: racy acccess in kern_runq.c

[Andrew Doran <ad%netbsd.org@localhost>]

On Fri, Dec 06, 2019 at 02:55:47PM +0000, Mindaugas Rasiukevicius wrote:

> 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,

Yup the rules around that are well understood.

> 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].

Thank you for the references, very interesting - if distressing - reading.
So it does happen.

> 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).

Well I'm firmly of the opinion that this is a bug in the compiler.  By all
means a nice behaviour to have as an option and I very much see the use of
it, but having it as the default for compiling old code is bad news indeed.

No argument from me on accommodating static analysers I think that's a good
thing.  Presumably then we have no other choice than to work around it,
because even if we can tell the compiler not to be a jerk today, that option
won't be feasible to use in the future.

Thanks again,
Andrew