Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757915AbYCCRjb (ORCPT ); Mon, 3 Mar 2008 12:39:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759154AbYCCRcF (ORCPT ); Mon, 3 Mar 2008 12:32:05 -0500 Received: from e31.co.us.ibm.com ([32.97.110.149]:53107 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759958AbYCCRcC (ORCPT ); Mon, 3 Mar 2008 12:32:02 -0500 Date: Mon, 3 Mar 2008 09:31:57 -0800 From: "Paul E. McKenney" To: Nick Piggin Cc: Alan Cox , Alan Stern , Pavel Machek , Linus Torvalds , Andrew Morton , Zdenek Kabelac , davem@davemloft.net, "Rafael J. Wysocki" , Pierre Ossman , Kernel development list , pm list Subject: Re: [patch] Re: using long instead of atomic_t when only set/read is required Message-ID: <20080303173157.GC12453@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20080303120842.GA28369@elf.ucw.cz> <20080303155330.39e45ad4@core> <200803040416.33937.nickpiggin@yahoo.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200803040416.33937.nickpiggin@yahoo.com.au> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1294 Lines: 32 On Tue, Mar 04, 2008 at 04:16:33AM +1100, Nick Piggin wrote: > On Tuesday 04 March 2008 02:53, Alan Cox wrote: > > > Atomicity of reads of write for pointers and integral types (other than > > > long long) should be documented. > > > > NAK. > > > > Atomicity of reads or writes for pointers and integral types is NOT > > guaranteed. Gcc doesn't believe in your guarantee. > > Are you sure gcc doesn't? Or is it just "C"? > > Linux wouldn't work today if gcc did something non-atomic there > (presuming you're talking about naturally aligned pointers/ints). > It is widely used and accepted. > > RCU users are far from the only places to rely on this, although > I guess they are the main ones when it comes to assigning pointers > atomically. It is true that gcc can refetch pointers/ints if it runs out of registers, which is why rcu_dereference() recently had an ACCESS_ONCE() added to it. But such refetching cannot result in a mish-mash of two different pointer values, confusing though it might be to the affected code. Thanx, Paul -- 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/