Messages in this thread | | | From | Dmitry Vyukov <> | Date | Sat, 5 Oct 2019 06:16:48 +0200 | Subject | Re: Kernel Concurrency Sanitizer (KCSAN) |
| |
On Sat, Oct 5, 2019 at 2:58 AM Eric Dumazet <eric.dumazet@gmail.com> wrote: > > This one is tricky. What I think we need to avoid is an onslaught of > > patches adding READ_ONCE/WRITE_ONCE without a concrete analysis of the > > code being modified. My worry is that Joe Developer is eager to get their > > first patch into the kernel, so runs this tool and starts spamming > > maintainers with these things to the point that they start ignoring KCSAN > > reports altogether because of the time they take up. > > > > I suppose one thing we could do is to require each new READ_ONCE/WRITE_ONCE > > to have a comment describing the racy access, a bit like we do for memory > > barriers. Another possibility would be to use atomic_t more widely if > > there is genuine concurrency involved. > > > > About READ_ONCE() and WRITE_ONCE(), we will probably need > > ADD_ONCE(var, value) for arches that can implement the RMW in a single instruction. > > WRITE_ONCE(var, var + value) does not look pretty, and increases register pressure.
FWIW modern compilers can handle this if we tell them what we are trying to do:
void foo(int *p, int x) { x += __atomic_load_n(p, __ATOMIC_RELAXED); __atomic_store_n(p, x, __ATOMIC_RELAXED); }
$ clang test.c -c -O2 && objdump -d test.o
0000000000000000 <foo>: 0: 01 37 add %esi,(%rdi) 2: c3 retq
We can have syntactic sugar on top of this of course.
| |