LWN: Comments on "Interrupts, threads, and lockdep"

Interrupts, threads, and lockdep

HalfMoon — Wed, 18 Mar 2009 02:45:00 +0000

Lockdep has worked this way for some time, and complaints have been scarce. But, as can be seen from the patch cited above, "scarce" is not the same as "nonexistent."

Also note that complaints about bugs introduced, or hidden, by lockdep forcibly setting IRQF_DISABLED have been disregarded. There are examples of both problem categories ... and that's in addition to the workaround cited in that patch fragment.

Interrupts, threads, and lockdep

tej.parkash — Mon, 16 Mar 2009 13:47:35 +0000

Sorry for not understanding core logic

What happens if lockdep is enabled, for interrupt handler which is implemented using threaded interrupt handler mechanism. If it disable then twl4030 problem remains there only right?

Interrupts, threads, and lockdep

abatters — Thu, 05 Mar 2009 03:08:31 +0000

> Unless a driver passes the IRQF_DISABLED flag when requesting its interrupt line, its interrupt handler will be called with interrupts enabled.

A minor clarification:

According to the Unreliable Guide To Locking, "it is architecture-specific whether all interrupts are disabled inside irq handlers themselves."

http://www.kernel.org/pub/linux/kernel/people/rusty/kerne...

If you use IRQF_DISABLED, then your interrupt handler is guaranteed to be called with interrupts disabled. If you don't use IRQF_DISABLED, then officially it is implementation-specific whether your interrupt handler is called with interrupts enabled or disabled. It is apparent from the rest of the article that the current implementation-specific behavior depends on CONFIG_LOCKDEP.

The important thing to remember when writing interrupt handlers is to use e.g. spin_lock_irqsave() instead of spin_lock_irq() (assuming you need a irq-disabling variant; see the Unreliable Guide To Locking for more details). Then it will work with CONFIG_LOCKDEP=y and CONFIG_LOCKDEP=n and on a wide variety of kernel versions.