On Wed, Oct 14, 2015 at 6:16 PM, Peter Zijlstra <pet...@infradead.org> wrote: > 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.
Well, if another thread writes it byte-by-byte, it pretty much does not matter how you read it. Note that I said "at least one access is not atomic". If both are atomic, then this is, of course, legal. And KTSAN considers READ/WRITE_ONCE as atomic operations. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
