Re: [tip:locking/urgent] compiler, atomics: Provide READ_ONCE_NOCHECK ()

[Peter Zijlstra]

On Wed, Oct 14, 2015 at 06:08:16PM +0200, Dmitry Vyukov wrote:
> >> > So I add READ_ONCE_NOCHECK() for accesses for which the compiler cannot
> >> > prove safe address for KASAN's benefit, but READ_ONCE() suffices for
> >> > the data-race-detection logic in KTSAN, correct?
> >>
> >> KTSAN also needs READ_ONCE_NOCHECK() here. KTSAN will flag races
> >> between get_wchan() and the thread accesses to own stack even more
> >> aggressively than KASAN, because KTSAN won't like get_wchan() accesses
> >> even to non-poisoned areas of other thread stack.
> >
> > So to keep KTSAN happy, any read from some other thread's stack requires
> > READ_ONCE_NOCHECK()?  What if the access is via a locking primitive or
> > read-modify-write atomic operation?
> >
> > This is of some interest in RCU, which implements synchronous grace
> > periods using completions that are allocated on the calling task's stack
> > and manipulated by RCU callbacks that are likely executing elsewhere.
> 
> 
> KTSAN does not have any special logic for stacks. It just generally
> flags pairs of accesses when (1) at least one access is not atomic,
> (2) at least one access is a write and (3) these accesses are not
> synchronized by means of other synchronization.

But but but.. WRITE_ONCE/READ_ONCE _are_ atomic when on naturally
aligned machine word sized thingies. We very much rely on that.

And the wchan thing is very much that, its not some weird large object,
its a single word, read with an explicit 'volatile' cast.

This is good, and should not require more magic annotations.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/