Re: [RFC] WRITE_ONCE_INC() and friends

[Petko Manolov <petko.manolov@konsulko.com>]

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