[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0803202301140.16520-100000@netrider.rowland.org>
Date: Thu, 20 Mar 2008 23:07:16 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Andrew Morton <akpm@...ux-foundation.org>
cc: Michael Buesch <mb@...sch.de>,
Henrique de Moraes Holschuh <hmh@....eng.br>,
David Brownell <david-b@...bell.net>,
Richard Purdie <rpurdie@...ys.net>,
<linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
<netdev@...r.kernel.org>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
<linux-usb@...r.kernel.org>, <linux-wireless@...r.kernel.org>,
<video4linux-list@...hat.com>,
Stefan Richter <stefanr@...6.in-berlin.de>,
<lm-sensors@...sensors.org>
Subject: Re: use of preempt_count instead of in_atomic() at leds-gpio.c
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 short, you are saying that there is _no_ reliable way to determine
am-i-called-from-inside-spinlock. Well, why isn't there? Would it be
so terrible if non-preemptible kernels did adjust preempt_count on
spin_lock/unlock?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists