In_irq() è affidabile?

Question

Unreliable Guide To Hacking The Linux Kernel afferma che

si può dire di essere in un interrupt di processo, perché in_irq() restituisce true.
Attenzione. Fai attenzione che questo restituirà un falso positivo se gli interrupt sono disabilitati (vedi sotto).

E 'davvero il caso che in_irq() può restituire non-zero non nel contesto hardirq nei kernel Linux 2.6.32 o più recenti su x86?

Nei miei esperimenti con il kernel 2.6.32 (Debian 6) e 3.4 (OpenSUSE 12.1), in_irq() sempre restituito 0 quando viene chiamato da un contesto di processo, anche se è stato chiamato tra il local_irq_disable() e . I risultati erano gli stessi quando ho usato le funzioni di spinlock che disabilitano gli interrupt invece di local_irq*.

dal codice sorgente del kernel, che al momento non riesco a vedere come in_irq() può restituire un falso positivo. Qualcuno potrebbe chiarirlo?

EDIT: Ho anche provato sia API spinlock *_irqsave() e *_irq() nonché local_irq_save()/local_irq_restore(), i risultati erano gli stessi, cioè, in_irq() restituito 0 quando gli interrupt sono stati disattivati. Disabilitare gli interrupt in modo esplicito tramite l'istruzione della macchina cli su x86 non ha forzato in_irq() di restituire un valore diverso da zero.

Answer 1

in_irq() è un involucro che looks at some bits in preempt_count, che è un int nella thread_info struct e un valore di 0 indica che non è ha anticipato quindi non è in un IRQ.

local_irq_disable() di per sé non influisce che contano, ma spin_lock_irqsave()does, in modo che potrebbe portare al falso positivo. Hai detto che hai usato le funzioni di spinlock, hai usato questo? In tal caso, controlla se il valore di preempt_count sta cambiando.

EDIT: Giusto per coprire tutte le basi, controllare per assicurarsi kernel prelazione è abilitato.