in_irq()可靠吗？

Question

不可靠的Linux内核黑客指南说

您可以知道您处于硬件中断中，因为in_irq()返回true。 警告。请注意，如果禁用中断，这将返回假阳性(见下文)。

在Linux2.6.32或更高版本的Linux2.6.32或更高版本的LinuxKernel2.6.32或更高版本中，in_irq()可能返回非零而不是hardirq上下文，这真的是这样吗？

在我对内核2.6.32 (Debian 6)和3.4 (OpenSUSE 12.1)进行的实验中，in_irq()在从进程上下文调用时总是返回0，即使它是在local_irq_disable()和local_irq_enable()之间调用的。当我使用spinlock函数来禁用中断而不是local_irq*时，结果是一样的。

从内核的源代码中，我目前无法看到in_irq()如何返回假阳性。有人能澄清这一点吗？

编辑:我也尝试过*_irqsave()和*_irq()自旋锁API以及local_irq_save() / local_irq_restore()，结果是一样的，也就是说，当中断被禁用时in_irq()返回0。通过cli机器指令显式地禁用x86上的中断也没有强制in_irq()返回非零。

Answer 1

in_irq()是一个包装器，preempt_count是thread_info结构中的int，值为0意味着它没有被抢占，所以它不在irq中。

local_irq_disable()本身并不影响计数，而是影响spin_lock_irqsave() 有吗？，因此可能导致假阳性。你说你使用了自旋锁函数，你用过这个函数吗？如果是，请查看preempt_count的值是否正在变化。

编辑:只是为了涵盖所有的基础，检查以确保内核抢占是启用的。