linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, laijs@cn.fujitsu.com,
	dipankar@in.ibm.com, akpm@linux-foundation.org,
	mathieu.desnoyers@efficios.com, josh@joshtriplett.org,
	niv@us.ibm.com, tglx@linutronix.de, peterz@infradead.org,
	rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com,
	darren@dvhart.com, fweisbec@gmail.com, sbw@mit.edu,
	Oleg Nesterov <oleg@redhat.com>, Jonathan Corbet <corbet@lwn.net>,
	Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH tip/core/locking 4/4] Documentation/memory-barriers.txt: Document ACCESS_ONCE()
Date: Tue, 10 Dec 2013 14:24:48 +0100	[thread overview]
Message-ID: <20131210132448.GA31366@gmail.com> (raw)
In-Reply-To: <20131205180200.GT15492@linux.vnet.ibm.com>


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

> On Thu, Dec 05, 2013 at 10:33:34AM +0100, Ingo Molnar wrote:
> > 
> > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> > 
> > > + (*) 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));
> > > +	}
> > 
> > Technically, if the interrupt handler is the innermost context, the 
> > ACCESS_ONCE() is not needed in the interrupt_handler() code.
> > 
> > Since for the vast majority of Linux code IRQ handlers are the most 
> > atomic contexts (very few drivers deal with NMIs) I suspect we should 
> > either remove that ACCESS_ONCE() from the example or add a comment 
> > explaining that in many cases those are superfluous?
> 
> How about the following additional paragraph?
> 
>      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.

Sounds great to me!

Note that nested IRQs generally don't happen on modern Linux anymore, 
we run almost all hardirqs with irqs disabled and in fact have a 
warning to detect irq handlers that enable irqs:

                res = action->handler(irq, action->dev_id);
                trace_irq_handler_exit(irq, action, res);

                if (WARN_ONCE(!irqs_disabled(),"irq %u handler %pF enabled interrupts\n",
                              irq, action->handler))
                        local_irq_disable();

Thanks,

	Ingo

  reply	other threads:[~2013-12-10 13:24 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-04 22:46 [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates Paul E. McKenney
2013-12-04 22:46 ` [PATCH tip/core/locking 1/4] Documentation/memory-barriers.txt: Add needed ACCESS_ONCE() calls to memory-barriers.txt Paul E. McKenney
2013-12-04 22:46   ` [PATCH tip/core/locking 2/4] Documentation/memory-barriers.txt: Add long atomic examples " Paul E. McKenney
2013-12-04 22:46   ` [PATCH tip/core/locking 4/4] Documentation/memory-barriers.txt: Document ACCESS_ONCE() Paul E. McKenney
2013-12-05  9:33     ` Ingo Molnar
2013-12-05  9:52       ` Mathieu Desnoyers
2013-12-05 10:11         ` Ingo Molnar
2013-12-05 18:02       ` Paul E. McKenney
2013-12-10 13:24         ` Ingo Molnar [this message]
2013-12-10 17:36           ` Paul E. McKenney
2013-12-05  9:50     ` Ingo Molnar
2013-12-05 18:05       ` Paul E. McKenney
2013-12-05 22:47         ` Paul E. McKenney
2013-12-10 15:10           ` Ingo Molnar
2013-12-10 17:37             ` Paul E. McKenney
2013-12-05 20:21     ` Jonathan Corbet
2013-12-05 21:44       ` Paul E. McKenney
2013-12-10 15:20         ` Ingo Molnar
2013-12-10 17:44           ` Paul E. McKenney
2013-12-10 18:28             ` Ingo Molnar
2013-12-10 19:01               ` Paul E. McKenney
2013-12-10 19:46                 ` Ingo Molnar
2013-12-10 20:09                   ` Paul E. McKenney
2013-12-05  0:10 ` [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates Josh Triplett
2013-12-05 10:59 ` Henrik Austad
2013-12-05 12:28   ` Ingo Molnar
2013-12-05 13:51     ` Steven Rostedt
2013-12-05 18:05       ` David Miller
2013-12-05 18:18         ` Paul E. McKenney
2013-12-05 18:44           ` David Miller
2013-12-05 19:01             ` Paul E. McKenney
2013-12-10 15:24         ` Ingo Molnar
2013-12-05 12:29   ` [PATCH v4 tip/core/locking 3/4] Documentation/memory-barriers.txt: Prohibit speculative writes Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131210132448.GA31366@gmail.com \
    --to=mingo@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=darren@dvhart.com \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=edumazet@google.com \
    --cc=fweisbec@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=niv@us.ibm.com \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=rusty@rustcorp.com.au \
    --cc=sbw@mit.edu \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).