lkml.org 
[lkml]   [2020]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2020-04-21 11:31    [W:0.053 / U:1.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site