Re: lockdep and threaded IRQs (was: ...)

Andrew Morton
2009-02-28T00:01:42Z

On Fri, 27 Feb 2009 15:32:04 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:

> Why does this function:
>
> static irqreturn_t powerbutton_irq(int irq, void *dev_id)
> {
> int err;
> u8 value;
>
> #ifdef CONFIG_LOCKDEP
> /* WORKAROUND for lockdep forcing IRQF_DISABLED on us, which
> * we don't want and can't tolerate. Although it might be
> * friendlier not to borrow this thread context...
> */
> local_irq_enable();
> #endif
>
> err = twl4030_i2c_read_u8(TWL4030_MODULE_PM_MASTER, &value,
> STS_HW_CONDITIONS);
> if (!err) {
> input_report_key(powerbutton_dev, KEY_POWER,
> value & PWR_PWRON_IRQ);
> } else {
> dev_err(dbg_dev, "twl4030: i2c error %d while reading TWL4030"
> " PM_MASTER STS_HW_CONDITIONS register\n", err);
> }
>
> return IRQ_HANDLED;
> }
>
> Which is connected up via this statement:
>
> err = request_irq(irq, powerbutton_irq,
> IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
> "twl4030-pwrbutton", NULL);
>
> reenable local interrupts?

ah, OK, twl4030_i2c_read_u8() does i2c I/O.

Can't do that. If some random process currently holds
mutex_lock(&twl->xfer_lock) and an interrupt occurs then this interrupt
handler will try to acquire mutex_lock(&twl->xfer_lock). Deadlock.