From: Arnd Bergmann <arnd@arndb.de>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Christoph Lameter <cl@linux-foundation.org>,
Tejun Heo <tj@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC local_t removal V1 1/4] Add add_local() and add_local_return()
Date: Thu, 7 Jan 2010 15:22:30 +0100 [thread overview]
Message-ID: <201001071522.30632.arnd@arndb.de> (raw)
In-Reply-To: <20100107135757.GA6011@Krystal>
On Thursday 07 January 2010, Mathieu Desnoyers wrote:
> * Arnd Bergmann (arnd@arndb.de) wrote:
> > > > + local_irq_save(flags);
> > > > + switch (size) {
> > > > + case 1: r = (*((u8 *)ptr) += value);
> > > > + break;
> > > > + case 2: r = (*((u16 *)ptr) += value);
> > > > + break;
> > > > + case 4: r = (*((u32 *)ptr) += value);
> > > > + break;
> > > > + case 8: r = (*((u64 *)ptr) += value);
> > > > + break;
> >
> > But I think here you actually need to add the volatile in order
> > to make these atomic assignments.
>
> Yes, you are right. If we ever try to access these variables from a
> remote CPU with a load (but not with any concurrent store operation, as
> this would be semantically invalid), then the volatile is important.
Just to make sure everyone has the same understanding: We need the volatile
in the cast in these lines, not the one in the function prototype which
only serves to avoid warnings but has no impact on the object code when
we cast the pointer to a non-volatile type for the assignment.
Arnd
next prev parent reply other threads:[~2010-01-07 14:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-05 22:04 [RFC local_t removal V1 0/4] Remove local_t Christoph Lameter
2010-01-05 22:04 ` [RFC local_t removal V1 1/4] Add add_local() and add_local_return() Christoph Lameter
2010-01-05 22:17 ` Mike Frysinger
2010-01-05 22:29 ` Christoph Lameter
2010-01-06 19:23 ` Mike Frysinger
2010-01-07 17:03 ` Christoph Lameter
2010-01-05 22:49 ` Mathieu Desnoyers
2010-01-07 13:45 ` Arnd Bergmann
2010-01-07 13:57 ` Mathieu Desnoyers
2010-01-07 14:22 ` Arnd Bergmann [this message]
2010-01-07 17:07 ` Christoph Lameter
2010-01-05 22:04 ` [RFC local_t removal V1 2/4] Replace local_t use in trace subsystem Christoph Lameter
2010-01-05 22:57 ` Mathieu Desnoyers
2010-01-07 17:15 ` Christoph Lameter
2010-01-14 2:56 ` Steven Rostedt
2010-01-14 14:49 ` Christoph Lameter
2010-01-05 22:04 ` [RFC local_t removal V1 3/4] Optimized add_local() Christoph Lameter
2010-01-05 22:59 ` Mathieu Desnoyers
2010-01-07 17:16 ` Christoph Lameter
2010-01-05 22:04 ` [RFC local_t removal V1 4/4] Remove local_t support Christoph Lameter
2010-01-05 22:23 ` [RFC local_t removal V1 0/4] Remove local_t Mathieu Desnoyers
2010-01-05 22:34 ` Christoph Lameter
2010-01-05 22:45 ` Mathieu Desnoyers
2010-01-07 17:05 ` Christoph Lameter
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=201001071522.30632.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=cl@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=tj@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.