On 2019/01/11 19:48, Dmitry Vyukov wrote: >> How did you arrive to the conclusion that it is harmless? >> There is only one relevant standard covering this, which is the C >> language standard, and it is very clear on this -- this has Undefined >> Behavior, that is the same as, for example, reading/writing random >> pointers. >> >> Check out this on how any race that you might think is benign can be >> badly miscompiled and lead to arbitrary program behavior: >> https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong > > Also there is no other practical definition of data race for automatic > data race detectors than: two conflicting non-atomic concurrent > accesses. Which this code is. Which means that if we continue writing > such code we are not getting data race detection and don't detect > thousands of races in kernel code that one may consider more harmful > than this one the easy way. And instead will spent large amounts of > time to fix some of then the hard way, and leave the rest as just too > hard to debug so let the kernel continue crashing from time to time (I > believe a portion of currently open syzbot bugs that developers just > left as "I don't see how this can happen" are due to such races). > I still cannot catch. Read/write of sizeof(long) bytes at naturally aligned address is atomic, isn't it? I'm not using increments etc. Therefore, in the worst case, some threads see outdated value. But outdated values affect only time_in_range() test, which does not cause severe problems like crash.
