lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Wed, 4 Feb 2009 20:30:28 +0300
From:	Andrey Borzenkov <arvidjaar@...l.ru>
To:	Linux Kernel Development <linux-kernel@...r.kernel.org>
Subject: How to atomically disable shared device interrupt?

May be I miss something obvious, but I do not see how is it possible to 
disable interrupt while also avoiding either "stealing" someone else's 
interrupt or getting "IRQ: nobody cared" occasionally.

So consider device that has status register that indicates events of 
interest that happened in device. Those events may also generate 
interrupt if interrupt generation is enabled; but they also are posted 
even if interrupt generation is disabled.

So to check whether interrupt handler should handle (shared) interrupt 
it a) checks that interrupts are currently enabled and b) that device 
indicates pending events.

No consider what happens when interrupts are disabled on device.

CPU1                       CPU2
IRQ posted
                        disable device interrupts
handler checks IRQ enabled
handler sees IRQ disabled
handler ignores interrupt

Actually the same race happens during enabling of interrupts

CPU1                       CPU2
IRQ enabled
                      other device posts IRQ
handler checks
  IRQ enabled
  events pending
  start processing

but IRQ was posted by some other device in the first place.

Any idea?

Download attachment "signature.asc " of type "application/pgp-signature" (198 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ