in_irq()可靠吗？

Question

黑客的不可靠指南Linux内核声明了这一点

你可以告诉你是在硬件中断,因为in_irq()返回true.
小心.请注意,如果禁用中断,这将返回误报(见下文).

是in_irq()不是在Linux内核2.6.32或更新的x86上的hardirq上下文中可能返回非零的情况？

在我使用内核2.6.32(Debian 6)和3.4(OpenSUSE 12.1)的实验中,in_irq()从进程上下文调用时总是返回0,即使它是在local_irq_disable()和之间调用的local_irq_enable().当我使用禁用中断而不是中断的自旋锁功能时,结果是相同的local_irq*.

从内核的源代码来看,我目前看不出如何in_irq()能够返回误报.任何人都可以澄清一下吗？

编辑:我也尝试了两个*_irqsave()和*_irq()spinlock API以及local_irq_save()/ local_irq_restore(),结果是相同的,即in_irq()中断被禁用时返回0.通过clix86 上的机器指令显式禁用中断也不会强制in_irq()返回非零值.

Answer 1

in_irq()是一个包装器，它查看 中的一些位preempt_count，它是 int 中的一个 intthread_info值，值为 0 意味着它没有被抢占，因此它不在 irq 中。

local_irq_disable()其本身不会影响该计数，但会影响该计数，因此可能会导致误报。你说你用过spinlock函数，你用过这个吗？如果是，请查看 preempt_count 的值是否发生变化。spin_lock_irqsave()

编辑：为了涵盖所有基础，请检查以确保启用内核抢占。