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]

Date:	Wed, 14 Oct 2015 09:23:33 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Dmitry Vyukov <dvyukov@...gle.com>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	tip-bot for Andrey Ryabinin <tipbot@...or.com>,
	"linux-tip-commits@...r.kernel.org" 
	<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>,
	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 9:20 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Wed, Oct 14, 2015 at 06:18:58PM +0200, Dmitry Vyukov wrote:
>>
>> 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.
>
> OK, then I'm confused on what exactly the annotation does, but less
> worried.

The annotation says "hey, KASAN (etc), don't worry if you think that
the memory being accessed is out of bounds".  Presumably KTSAN is okay
with the operation because it's atomic, but KASAN dislikes it because
it's accessing memory that is out of bounds from the perspective of a
C program.

I'd still rather find a way to just delete get_wchan, but whatever.

--Andy
--
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/