lkml.org 
[lkml]   [2013]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH tip/core/locking 4/4] Documentation/memory-barriers.txt: Document ACCESS_ONCE()

* Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:

> > +for barrier() that affects only the specific accesses flagged by the
> > +ACCESS_ONCE().
> >
> > Does not seem to be obvious enough to me - does it affect accesses
> > to the variables referenced (but still allows accesses to separate
> > variables reordered), or does it affect compiler-ordering of all
> > ACCESS_ONCE() instances, instructing the compiler to preserve
> > program order?
>
> I cover this in the bullet item about reordering memory accesses:
>
> (*) The compiler is within its rights to reorder memory accesses unless
> you tell it not to. For example, consider the following interaction
> between process-level code and an interrupt handler:
>
> void process_level(void)
> {
> msg = get_message();
> flag = true;
> }
>
> void interrupt_handler(void)
> {
> if (flag)
> process_message(msg);
> }
>
> There is nothing to prevent the the compiler from transforming
> process_level() to the following, in fact, this might well be a
> win for single-threaded code:
>
> void process_level(void)
> {
> flag = true;
> msg = get_message();
> }
>
> If the interrupt occurs between these two statement, then
> interrupt_handler() might be passed a garbled msg. Use ACCESS_ONCE()
> to prevent this as follows:
>
> void process_level(void)
> {
> ACCESS_ONCE(msg) = get_message();
> ACCESS_ONCE(flag) = true;
> }
>
> void interrupt_handler(void)
> {
> if (ACCESS_ONCE(flag))
> process_message(ACCESS_ONCE(msg));
> }
>
> Note that the ACCESS_ONCE() wrappers in interrupt_handler()
> are needed if this interrupt handler can itself be interrupted
> by something that also accesses 'flag' and 'msg', for example,
> a nested interrupt or an NMI. Otherwise, ACCESS_ONCE() is not
> needed in interrupt_handler() other than for documentation purposes.
> (Note also that nested interrupts do not typically occur in modern
> Linux kernels, in fact, if an interrupt handler returns with
> interrupts enabled, you will get a WARN_ONCE() splat.)
>
> This effect could also be achieved using barrier(), but ACCESS_ONCE()
> is more selective: With ACCESS_ONCE(), the compiler need only forget
> the contents of the indicated memory located, while with barrier()
> the compiler must discard the value of all memory locations that
> it has currented cached in any machine registers.
>
> Does that cover it?

btw.:

s/indicated memory located/
indicated memory location

?

So, what I don't see this statement cover (and I might be dense about
it!) is whether two ACCESS_ONCE() macros referring to different
variables are allowed to be reordered with each other.

If the compiler reorders:

ACCESS_ONCE(x);
ACCESS_ONCE(y);

to:

ACCESS_ONCE(y);
ACCESS_ONCE(x);

then AFAICS it still meets the "compiler need only forget the contents
of the indicated memory located" requirement that you listed, right?

[ I have a good excuse for asking this: after a long day my IQ dropped
by 50 points and all that! :-) ]

Thanks,

Ingo


\
 
 \ /
  Last update: 2013-12-10 20:01    [W:0.075 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site