Date: Wed, 1 Jul 2009 23:11:17 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Howells <dhowells@redhat.com>, akpm@linux-foundation.org,
       paulus@samba.org, arnd@arndb.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] FRV: Implement atomic64_t
Message-ID: <20090701211117.GC631@elte.hu>
References: <20090701144913.GA28172@elte.hu> <20090701164700.29780.15103.stgit@warthog.procyon.org.uk> <alpine.LFD.2.01.0907011004000.3605@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.01.0907011004000.3605@localhost.localdomain>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1251
Lines: 34


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Wed, 1 Jul 2009, David Howells wrote:
> > +
> > +#define ATOMIC64_INIT(i)	{ (i) }
> > +#define atomic64_read(v)	((v)->counter)
> > +#define atomic64_set(v, i)	(((v)->counter) = (i))
> 
> These seem to be buggy.
> 
> At least "atomic64_read()" needs to make sure to actually read it 
> atomically - otherwise you'll do two 32-bit reads, and that just 
> gets crap. Imagine if somebody is adding 1 to 0x00000000ffffffff, 
> and then "atomic64_read()" reads it as two accesses in the wrong 
> place, and gets either 0, or 0x00000001ffffffff, both of which are 
> totally incorrect.
> 
> The case of 'atomic64_set()' is _slightly_ less clear, because I 
> think we use it mostly for initializers, so atomicity is often not 
> strictly required. But at least on x86, we do guarantee that it 
> sets it atomically too.
> 
> Btw, Ingo: I looked at the x86-32 versions to be sure, and noticed 
> a couple of buglets:

thanks - we'll fix these!

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/