Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936746AbXHPAqc (ORCPT ); Wed, 15 Aug 2007 20:46:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754938AbXHPAqU (ORCPT ); Wed, 15 Aug 2007 20:46:20 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:53239 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754860AbXHPAqS (ORCPT ); Wed, 15 Aug 2007 20:46:18 -0400 Date: Thu, 16 Aug 2007 06:28:42 +0530 (IST) From: Satyam Sharma X-X-Sender: satyam@enigma.security.iitk.ac.in To: Herbert Xu cc: Segher Boessenkool , horms@verge.net.au, Stefan Richter , Linux Kernel Mailing List , "Paul E. McKenney" , ak@suse.de, netdev@vger.kernel.org, cfriesen@nortel.com, Heiko Carstens , rpjday@mindspring.com, jesper.juhl@gmail.com, linux-arch@vger.kernel.org, Andrew Morton , zlynx@acm.org, clameter@sgi.com, schwidefsky@de.ibm.com, Chris Snook , davem@davemloft.net, Linus Torvalds , wensong@linux-vs.org, wjiang@resilience.com Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures In-Reply-To: <20070816003226.GA29491@gondor.apana.org.au> Message-ID: References: <46C30540.2070603@s5r6.in-berlin.de> <20070815145207.GA23106@gondor.apana.org.au> <46C3253F.5090707@s5r6.in-berlin.de> <20070815162722.GD9645@linux.vnet.ibm.com> <20070815185724.GH9645@linux.vnet.ibm.com> <2d2eeab6276cab2e6cc5830d36a43b98@kernel.crashing.org> <20070816003226.GA29491@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1376 Lines: 35 [ Sorry for empty subject line in previous mail. I intended to make a patch so cleared it to change it, but ultimately neither made a patch nor restored subject line. Done that now. ] On Thu, 16 Aug 2007, Herbert Xu wrote: > On Thu, Aug 16, 2007 at 06:06:00AM +0530, Satyam Sharma wrote: > > > > that are: > > > > while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) { > > mdelay(1); > > msecs--; > > } > > > > where mdelay() becomes __const_udelay() which happens to be in another > > translation unit (arch/i386/lib/delay.c) and hence saves this callsite > > from being a bug :-) > > The udelay itself certainly should have some form of cpu_relax in it. Yes, a form of barrier() must be present in mdelay() or udelay() itself as you say, having it in __const_udelay() is *not* enough (superflous actually, considering it is already a separate translation unit and invisible to the compiler). However, there are no compiler barriers on the macro-definition-path between mdelay(1) and __const_udelay(), so the only thing that saves us from being a bug here is indeed the different-translation-unit concept. - 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/