Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755241Ab1EDTIg (ORCPT ); Wed, 4 May 2011 15:08:36 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:39177 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754387Ab1EDTIe (ORCPT ); Wed, 4 May 2011 15:08:34 -0400 MIME-Version: 1.0 In-Reply-To: References: <20110504083559.GB25724@elte.hu> <20110504101932.GA3392@elte.hu> <20110504112746.GE8007@htj.dyndns.org> <20110504132022.GA17294@htj.dyndns.org> <20110504142532.GC17294@htj.dyndns.org> From: Linus Torvalds Date: Wed, 4 May 2011 12:07:42 -0700 Message-ID: Subject: Re: [block IO crash] Re: 2.6.39-rc5-git2 boot crashs To: Christoph Lameter Cc: Pekka Enberg , Thomas Gleixner , Tejun Heo , Ingo Molnar , Jens Axboe , Andrew Morton , werner , "H. Peter Anvin" , Linux Kernel Mailing List Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1514 Lines: 38 On Wed, May 4, 2011 at 11:49 AM, Christoph Lameter wrote: > > The unprotected version is the __this_cpu_cmpxchg_double? That currently > has no user and could be removed. But all other functions also have __ > variants so it was put there for symmetries sake. No, I'm talking about the regular "this_cpu_cmpxchg_double" with no underscores. Why the f*!@ does that exist? Why the f*%^ do you have to write "irqsafe", when the whole concept DOES NOT MAKE SENSE without the "irqsafe"? Why did we have this bug in the first place, in other words? The whole interface was mis-designed, and pretty much designed to cause bugs. I think we should remove every single version of "this_cpu_cmpxchg_double" except for two: the per-cpu one and the SMP-safe one. And the per-cpu one doesn't mention "irqsafe" or "preempt" or anything like that, because the whole function makes no sense except when it is irq-safe and preempt-safe. So I think the fact that we need to say "irqsafe" is a bug. Plain and simple. The whole (and ONLY) point of "cmpxchg" is atomicity. This is not like "add one to something". That's an operation that makes sense outside of atomicity issues. But "cmpxchg" is all about being atomic. Linus -- 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/