Messages in this thread | | | Date | Thu, 20 Mar 2008 23:07:16 -0400 (EDT) | From | Alan Stern <> | 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
| |