Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760842AbXHQIjP (ORCPT ); Fri, 17 Aug 2007 04:39:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756056AbXHQIi7 (ORCPT ); Fri, 17 Aug 2007 04:38:59 -0400 Received: from smtp107.mail.mud.yahoo.com ([209.191.85.217]:40363 "HELO smtp107.mail.mud.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752282AbXHQIi4 (ORCPT ); Fri, 17 Aug 2007 04:38:56 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=PCYtnO9azp6GHR3hMTLrezqefjBZmVcmTt9XEOGThZBfbNNXO4yTjmWZtuudaoNfuY4SDGwPcFxuw3nxlSlb3xrRnM7fTynRabhfu5/IodTEtNqRWmwYiXst5I9RdkjGS1dniQPR3Zow0vzmfmRLEy/aPKj9u+sDdod/F1JuLC0= ; X-YMail-OSG: YKf3vfUVM1lUFc4nL9eVfK3GCwLcxA9EoHmw8v_XQIosuKQiQZ7CNAFoTdpq8kaYZE1TzFhVOw-- Message-ID: <46C55E90.7010407@yahoo.com.au> Date: Fri, 17 Aug 2007 18:38:40 +1000 From: Nick Piggin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051007 Debian/1.7.12-1 X-Accept-Language: en MIME-Version: 1.0 To: Satyam Sharma CC: Herbert Xu , Paul Mackerras , Linus Torvalds , Christoph Lameter , Chris Snook , Ilpo Jarvinen , "Paul E. McKenney" , Stefan Richter , Linux Kernel Mailing List , linux-arch@vger.kernel.org, Netdev , Andrew Morton , ak@suse.de, heiko.carstens@de.ibm.com, David Miller , schwidefsky@de.ibm.com, wensong@linux-vs.org, horms@verge.net.au, wjiang@resilience.com, cfriesen@nortel.com, zlynx@acm.org, rpjday@mindspring.com, jesper.juhl@gmail.com, segher@kernel.crashing.org Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures References: <18115.52863.638655.658466@cargo.ozlabs.ibm.com> <20070816053945.GB32442@gondor.apana.org.au> <18115.62741.807704.969977@cargo.ozlabs.ibm.com> <20070816070907.GA964@gondor.apana.org.au> <46C4ABA5.9010804@redhat.com> <18117.1287.779351.836552@cargo.ozlabs.ibm.com> <18117.6495.397597.582736@cargo.ozlabs.ibm.com> <20070817035342.GA14744@gondor.apana.org.au> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2686 Lines: 80 Satyam Sharma wrote: > > On Fri, 17 Aug 2007, Herbert Xu wrote: > > >>On Fri, Aug 17, 2007 at 01:43:27PM +1000, Paul Mackerras wrote: >> >>BTW, the sort of missing barriers that triggered this thread >>aren't that subtle. It'll result in a simple lock-up if the >>loop condition holds upon entry. At which point it's fairly >>straightforward to find the culprit. > > > Not necessarily. A barrier-less buggy code such as below: > > atomic_set(&v, 0); > > ... /* some initial code */ > > while (atomic_read(&v)) > ; > > ... /* code that MUST NOT be executed unless v becomes non-zero */ > > (where v->counter is has no volatile access semantics) > > could be generated by the compiler to simply *elid* or *do away* with > the loop itself, thereby making the: > > "/* code that MUST NOT be executed unless v becomes non-zero */" > > to be executed even when v is zero! That is subtle indeed, and causes > no hard lockups. Then I presume you mean while (!atomic_read(&v)) ; Which is just the same old infinite loop bug solved with cpu_relax(). These are pretty trivial to audit and fix, and also to debug, I would think. > Granted, the above IS buggy code. But, the stated objective is to avoid > heisenbugs. Anyway, why are you making up code snippets that are buggy in other ways in order to support this assertion being made that lots of kernel code supposedly depends on volatile semantics. Just reference the actual code. > And we have driver / subsystem maintainers such as Stefan > coming up and admitting that often a lot of code that's written to use > atomic_read() does assume the read will not be elided by the compiler. So these are broken on i386 and x86-64? Are they definitely safe on SMP and weakly ordered machines with just a simple compiler barrier there? Because I would not be surprised if there are a lot of developers who don't really know what to assume when it comes to memory ordering issues. This is not a dig at driver writers: we still have memory ordering problems in the VM too (and probably most of the subtle bugs in lockless VM code are memory ordering ones). Let's not make up a false sense of security and hope that sprinkling volatile around will allow people to write bug-free lockless code. If a writer can't be bothered reading API documentation and learning the Linux memory model, they can still be productive writing safely locked code. -- SUSE Labs, Novell Inc. - 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/