Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758980AbYCUQza (ORCPT ); Fri, 21 Mar 2008 12:55:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755345AbYCUQzM (ORCPT ); Fri, 21 Mar 2008 12:55:12 -0400 Received: from einhorn.in-berlin.de ([192.109.42.8]:34027 "EHLO einhorn.in-berlin.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754603AbYCUQzL (ORCPT ); Fri, 21 Mar 2008 12:55:11 -0400 X-Envelope-From: stefanr@s5r6.in-berlin.de Message-ID: <47E3E83F.3070508@s5r6.in-berlin.de> Date: Fri, 21 Mar 2008 17:54:23 +0100 From: Stefan Richter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080219 SeaMonkey/1.1.8 MIME-Version: 1.0 To: Tetsuo Handa CC: akpm@linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: use of preempt_count instead of in_atomic() at leds-gpio.c References: <20080320192719.6a32386e.akpm@linux-foundation.org> <20080320201723.b87b3732.akpm@linux-foundation.org> <200803220011.CEC82820.QSOtJOVFFHFMLO@I-love.SAKURA.ne.jp> In-Reply-To: <200803220011.CEC82820.QSOtJOVFFHFMLO@I-love.SAKURA.ne.jp> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1503 Lines: 33 Tetsuo Handa wrote: > Hello. > >>> In short, you are saying that there is _no_ reliable way to determine >>> am-i-called-from-inside-spinlock. >> That's correct. > > So, it is impossible to know whether I am inside a spinlock or not. > OK. That's not what I want to do. > > I want to make sure that my code (not a device driver) is called only from a context > where use of down()/mutex_lock()/kmalloc(GFP_KERNEL)/get_user_pages()/kmap() etc. are permitted. > Is "if (in_atomic()) return;" check a correct method for avoiding deadlocks > when my code was accidentally called from a context > where use of down()/mutex_lock()/kmalloc(GFP_KERNEL)/get_user_pages()/kmap() etc. are not permitted? > I'm assuming that in_atomic() returns nonzero whenever scheduling is not permitted. You shouldn't sleep while holding a spinlock. As soon as another thread attempts to take the spinlock, it will be stuck in a busy-wait loop. So, it's better if you specify that your code either can be called in atomic context or must not be called in atomic context, and all callers observe this restriction. Or callers pass a flag to your code which says whether your code is allowed to sleep or not. -- Stefan Richter -=====-==--- --== =-=-= http://arcgraph.de/sr/ -- 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/