linux-kernel - Re: [tip:locking/urgent] compiler, atomics: Provide READ_ONCE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151014161615.GG3816@twins.programming.kicks-ass.net>
Date:	Wed, 14 Oct 2015 18:16:15 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Dmitry Vyukov <dvyukov@...gle.com>
Cc:	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	tip-bot for Andrey Ryabinin <tipbot@...or.com>,
	linux-tip-commits@...r.kernel.org,
	kasan-dev <kasan-dev@...glegroups.com>,
	Ingo Molnar <mingo@...nel.org>,
	Kostya Serebryany <kcc@...gle.com>,
	Borislav Petkov <bp@...en8.de>,
	Andrey Ryabinin <aryabinin@...tuozzo.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Sasha Levin <sasha.levin@...cle.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Wolfram Gloger <wmglo@...t.med.uni-muenchen.de>,
	Andrey Konovalov <andreyknvl@...gle.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Alexander Potapenko <glider@...gle.com>
Subject: Re: [tip:locking/urgent] compiler, atomics: Provide
 READ_ONCE_NOCHECK ()

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/