On 05/09, Paul E. McKenney wrote: > > On Thu, May 09, 2024 at 05:13:12PM +0200, Oleg Nesterov wrote: > > > > We can move these WARN_ON()'s into the ->rss_lock protected section. > > > > Or perhaps we can use data_race(rsp->gp_count) ? To be honest I thought > > that READ_ONCE() should be enough... > > > > Or we can simply kill these WARN_ON_ONCE()'s. > > Or we could move those WARN_ON_ONCE() under the lock. Sure, see above. But could you help me to understand this magic? I naively thought that READ_ONCE() is always "safe"... So, unless I am totally confused it turns out that, say, CPU 0 CPU 1 ----- ----- spin_lock(LOCK); ++X; READ_ONCE(X); // data race spin_unlock(LOCK); is data-racy accoring to KCSAN, while CPU 0 CPU 1 ----- ----- spin_lock(LOCK); WRITE_ONCE(X, X+1); READ_ONCE(X); // no data race spin_unlock(LOCK); is not. Why is that? Trying to read Documentation/dev-tools/kcsan.rst... it says KCSAN is aware of *marked atomic operations* (``READ_ONCE``, WRITE_ONCE``, ... if all accesses to a variable that is accessed concurrently are properly marked, KCSAN will never trigger a watchpoint but how can KCSAN detect that all accesses to X are properly marked? I see nothing KCSAN-related in the definition of WRITE_ONCE() or READ_ONCE(). And what does the "all accesses" above actually mean? The 2nd version does WRITE_ONCE(X, X+1); but "X + 1" is the plain/unmarked access? Thanks, Oleg.
