linux-kernel - Re: [RFC] WRITE_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:   Tue, 21 Apr 2020 12:30:47 +0300
From:   Petko Manolov <petko.manolov@...sulko.com>
To:     David Laight <David.Laight@...LAB.COM>
Cc:     "Paul E. McKenney" <paulmck@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] WRITE_ONCE_INC() and friends

On 20-04-21 08:00:48, David Laight wrote:
> From: Petko Manolov
> > Sent: 20 April 2020 17:32
> ...
> > > But one downside of declaring variables volatile is that it can prevent 
> > > KCSAN from spotting violations of the concurrency design for those 
> > > variables.
> > 
> > Which would be unfortunate.
> > 
> > I just wish there was C type declaration that would force the compiler to do 
> > what READ/WRITE_ONCE() does now, but i also know this is too naive... :)
> 
> It does, it is called 'volatile'.

Well, it doesn't.  I'd hate it if this thread become too academic so please 
read:

	https://lwn.net/Articles/233482/

I am really bad in naming things, but assume that something like "shared int a" 
tells the compiler everything what READ_ONCE(a) would if it was only "int a".  
Here "shared" is the magic qualifier.

	shared int a, b;

	a = x;
	y = b;

The compiler should also be forbidden from reordering these two statements, 
perform exactly one store to "a", exactly one load from "b", etc, etc.  IOW just 
like with:

	WRITE_ONCE(a, x);
	y = READ_ONCE(b);

> All READ_ONCE() does is force the access through a volatile pointer.

It does a lot more than that.  Again, please read the comments in:

	include/linux/compiler.h

> The thing to do is mark the structure elements 'volatile' rather than using a 
> 'pointer to volatile structure'.

Err, don't see the point in either of these.  It won't replace the need of 
locking or using some sort of barrier if these were to be used as some sort of 
shared memory.

> I'm sure KASAN could be taught about volatile structure members.

That it may.

		Petko