[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46C41EE4.9090806@s5r6.in-berlin.de>
Date: Thu, 16 Aug 2007 11:54:44 +0200
From: Stefan Richter <stefanr@...6.in-berlin.de>
To: Herbert Xu <herbert@...dor.apana.org.au>
CC: Paul Mackerras <paulus@...ba.org>,
Satyam Sharma <satyam@...radead.org>,
Christoph Lameter <clameter@....com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Chris Snook <csnook@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-arch@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
netdev@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>,
ak@...e.de, heiko.carstens@...ibm.com, davem@...emloft.net,
schwidefsky@...ibm.com, wensong@...ux-vs.org, horms@...ge.net.au,
wjiang@...ilience.com, cfriesen@...tel.com, zlynx@....org,
rpjday@...dspring.com, jesper.juhl@...il.com,
segher@...nel.crashing.org
Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all
architectures
Herbert Xu wrote:
> On Thu, Aug 16, 2007 at 10:06:31AM +0200, Stefan Richter wrote:
>> >
>> > Do you (or anyone else for that matter) have an example of this?
>>
>> The only code I somewhat know, the ieee1394 subsystem, was perhaps
>> authored and is currently maintained with the expectation that each
>> occurrence of atomic_read actually results in a load operation, i.e. is
>> not optimized away. This means all atomic_t (bus generation, packet and
>> buffer refcounts, and some other state variables)* and likewise all
>> atomic bitops in that subsystem.
>
> Can you find an actual atomic_read code snippet there that is
> broken without the volatile modifier?
What do I have to look for? atomic_read after another read or write
access to the same variable, in the same function scope? Or in the sum
of scopes of functions that could be merged by function inlining?
One example was discussed here earlier: The for (;;) loop in
nodemgr_host_thread. There an msleep_interruptible implicitly acted as
barrier (at the moment because it's in a different translation unit; if
it were the same, then because it hopefully has own barriers). So that
happens to work, although such an implicit barrier is bad style: Better
enforce the desired behaviour (== guaranteed load operation) *explicitly*.
--
Stefan Richter
-=====-=-=== =--- =----
http://arcgraph.de/sr/
-
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