Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754809AbYCUDUB (ORCPT ); Thu, 20 Mar 2008 23:20:01 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753194AbYCUDTt (ORCPT ); Thu, 20 Mar 2008 23:19:49 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:53434 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753024AbYCUDTr (ORCPT ); Thu, 20 Mar 2008 23:19:47 -0400 Date: Thu, 20 Mar 2008 20:17:23 -0700 From: Andrew Morton To: Alan Stern Cc: Michael Buesch , Henrique de Moraes Holschuh , David Brownell , Richard Purdie , , Ingo Molnar , Geert Uytterhoeven , , Martin Schwidefsky , Heiko Carstens , , , , Stefan Richter , Subject: Re: use of preempt_count instead of in_atomic() at leds-gpio.c Message-Id: <20080320201723.b87b3732.akpm@linux-foundation.org> In-Reply-To: References: <20080320192719.6a32386e.akpm@linux-foundation.org> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.5; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2343 Lines: 55 On Thu, 20 Mar 2008 23:07:16 -0400 (EDT) Alan Stern wrote: > On Thu, 20 Mar 2008, Andrew Morton wrote: > > > > > > Now, it happens that in_atomic() returns true on non-preemtible kernels > > > > > when running in interrupt or softirq context. But if the above code really > > > > > is using in_atomic() to detect am-i-called-from-interrupt and NOT > > > > > am-i-called-from-inside-spinlock, they should be using in_irq(), > > > > > in_softirq() or in_interrupt(). > > > > > > > > Presumably most of these places are actually trying to detect > > > > am-i-allowed-to-sleep. Isn't that what in_atomic() is supposed to do? > > > > > > No, I think there is no such check in the kernel. Most likely for performance > > > reasons, as it would require a global flag that is set on each spinlock. > > > > Yup. non-preemptible kernels avoid the inc/dec of > > current_thread_info->preempt_count on spin_lock/spin_unlock > > So then what's the point of having in_atomic() at all? Is it nothing > more than a shorthand form of (in_irq() | in_softirq() | > in_interrupt())? in_atomic() is for core kernel use only. Because in special circumstances (ie: kmap_atomic()) we run inc_preempt_count() even on non-preemptible kernels to tell the per-arch fault handler that it was invoked by copy_*_user() inside kmap_atomic(), and it must fail. > In short, you are saying that there is _no_ reliable way to determine > am-i-called-from-inside-spinlock. That's correct. > Well, why isn't there? The reasons I identified: it adds additional overhead and it encourages poorly-thought-out design. Now we _could_ change kernel design principles from caller-knows-whats-going-on over to callee-works-out-whats-going-on. But that would affect more than this particular thing. > Would it be > so terrible if non-preemptible kernels did adjust preempt_count on > spin_lock/unlock? The vast, vast majority of kernel code has managed to get through life without needing this hidden-argument-passing. The handful of errant callsites should be able to do so as well... -- 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/