Messages in this thread | | | Subject | Re: Kernel Concurrency Sanitizer (KCSAN) | From | Eric Dumazet <> | Date | Fri, 4 Oct 2019 17:58:33 -0700 |
| |
On 9/20/19 8:54 AM, Will Deacon 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.
I had a look at first KCSAN reports, and I can tell that tcp_poll() being lockless means we need to add hundreds of READ_ONCE(), WRITE_ONCE() and ADD_ONCE() all over the places.
-> Absolute nightmare for future backports to stable branches.
| |