Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752463Ab1EDUdD (ORCPT ); Wed, 4 May 2011 16:33:03 -0400 Received: from smtp110.prem.mail.ac4.yahoo.com ([76.13.13.93]:41335 "HELO smtp110.prem.mail.ac4.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751126Ab1EDUdB (ORCPT ); Wed, 4 May 2011 16:33:01 -0400 X-Yahoo-SMTP: _Dag8S.swBC1p4FJKLCXbs8NQzyse1SYSgnAbY0- X-YMail-OSG: enLLWPoVM1ltqiQ6Jd3ULUFl1.vEbxXifEZqjS3PxprAn0r ST8jIT6dDhIDANzIUGJrfGdP4bVhYGCVycLrMzERS1Bcj7JMjmpJbRXUDNim P50E5MO5vl6M56y4yjMWsyhG0Jy78hqrdWeFfk2ryjY_ivZwsUPD00R.cdqy B41oKbZI2g8hPXKBcTfPzyznUzcK2UZaCEUpnkgqAaP.etEuWCSYVafwtFP0 AoKpidSVOMP4xJU7EIw6lfA_Kag88A.PPJqpHx8TjoirJw2ZzRidr4Wgw.pB 6hTIsu7a2B1cm.Cg6syLrC1RWVHIDH03OO9ns6bd1A8_HXq2i X-Yahoo-Newman-Property: ymail-3 Date: Wed, 4 May 2011 15:32:55 -0500 (CDT) From: Christoph Lameter X-X-Sender: cl@router.home To: Valdis.Kletnieks@vt.edu cc: Linus Torvalds , Pekka Enberg , Thomas Gleixner , Tejun Heo , Ingo Molnar , Jens Axboe , Andrew Morton , werner , "H. Peter Anvin" , Linux Kernel Mailing List Subject: Re: [block IO crash] Re: 2.6.39-rc5-git2 boot crashs In-Reply-To: <19422.1304540499@localhost> Message-ID: References: <20110504112746.GE8007@htj.dyndns.org> <20110504132022.GA17294@htj.dyndns.org> <20110504142532.GC17294@htj.dyndns.org> <19422.1304540499@localhost> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1106 Lines: 27 On Wed, 4 May 2011, Valdis.Kletnieks@vt.edu wrote: > On Wed, 04 May 2011 15:04:39 CDT, Christoph Lameter said: > > On Wed, 4 May 2011, Linus Torvalds wrote: > > > > But cmpxchg DOES NOT MAKE SENSE without atomicity guarantees. > > > > This is not a real cmpxchg after all. Its not atomic in the sense of > > other functions. Its only "percpu atomic" if you want it that way. This is > > *not* a full cmpxchg_double(). > > Calling it a cmpxchg when it doesn't have the primary distinguishing property > of a hardware cmpxchg is just loading a bullet in the chamber and inviting > kernel hackers to point it at their feet... It does have most of the distinguishing characterstics but the lock-prefixless cmpxchg8b/16b (which is quite fast) is used in a unique way here in a percpu fastdpath. Thats why we have the strange naming this_cpu_cmpxchg_double etc. -- 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/