On Fri, Jan 11, 2019 at 11:40 AM Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > > On Fri, Jan 11, 2019 at 11:28 AM Tetsuo Handa > <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On 2019/01/11 19:19, Dmitry Vyukov wrote: > > >> @@ -200,6 +200,7 @@ void end_buffer_write_sync(struct buffer_head *bh, int uptodate) > > >> struct buffer_head *head; > > >> struct page *page; > > >> int all_mapped = 1; > > >> + static unsigned long last; > > > > > > /\/\/\/\/\/\ > > > > > > We will have to re-fix this when we start testing with KTSAN, data > > > race detector. > > > > What's wrong? This race is harmless. > > 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).
