[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1297858734.23343.138.camel@gandalf.stny.rr.com>
Date: Wed, 16 Feb 2011 07:18:54 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Will Newton <will.newton@...il.com>
Cc: Will Simoneau <simoneau@....uri.edu>,
David Miller <davem@...emloft.net>, hpa@...or.com,
matt@...sole-pimps.org, peterz@...radead.org, jbaron@...hat.com,
mathieu.desnoyers@...ymtl.ca, mingo@...e.hu, tglx@...utronix.de,
andi@...stfloor.org, roland@...hat.com, rth@...hat.com,
masami.hiramatsu.pt@...achi.com, fweisbec@...il.com,
avi@...hat.com, sam@...nborg.org, ddaney@...iumnetworks.com,
michael@...erman.id.au, linux-kernel@...r.kernel.org,
vapier@...too.org, cmetcalf@...era.com, dhowells@...hat.com,
schwidefsky@...ibm.com, heiko.carstens@...ibm.com,
benh@...nel.crashing.org
Subject: Re: [PATCH 0/2] jump label: 2.6.38 updates
On Wed, 2011-02-16 at 10:15 +0000, Will Newton wrote:
> > That's some really crippled hardware... it does seem like *any* loads
> > from *any* address updated by an sc would have to be done with ll as
> > well, else they may load stale values. One could work this into
> > atomic_read(), but surely there are other places that are problems.
>
> I think it's actually ok, atomics have arch implemented accessors, as
> do spinlocks and atomic bitops. Those are the only place we do sc so
> we can make sure we always ll or invalidate manually.
I'm curious, how is cmpxchg() implemented on this architecture? As there
are several places in the kernel that uses this on regular variables
without any "accessor" functions.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists