From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Buesch Subject: Re: use of preempt_count instead of in_atomic() at leds-gpio.c Date: Fri, 21 Mar 2008 02:36:51 +0100 Message-ID: <200803210236.52063.mb@bu3sch.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Andrew Morton , Henrique de Moraes Holschuh , David Brownell , Richard Purdie , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Ingo Molnar , Geert Uytterhoeven , netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Martin Schwidefsky , Heiko Carstens , linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, video4linux-list-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Stefan Richter , lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org To: Alan Stern Return-path: In-Reply-To: Content-Disposition: inline Sender: linux-wireless-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org On Friday 21 March 2008 02:31:44 Alan Stern wrote: > On Thu, 20 Mar 2008, Andrew Morton wrote: > > > On Thu, 20 Mar 2008 21:36:04 -0300 Henrique de Moraes Holschuh wrote: > > > > > Well, so far so good for LEDs, but what about the other users of in_atomic > > > that apparently should not be doing it either? > > > > Ho hum. Lots of cc's added. > > ... > > > The usual pattern for most of the above is > > > > if (!in_atomic()) > > do_something_which_might_sleep(); > > > > problem is, in_atomic() returns false inside spinlock on non-preptible > > kernels. So if anyone calls those functions inside spinlock they will > > incorrectly schedule and another task can then come in and try take the > > already-held lock. > > > > 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. You simply must always _know_, if you are allowed to sleep or not. This is done by defining an API. The call-context is part of any kernel API. -- Greetings Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html