linux-kernel - [REGRESSION] threaded interrupt handler support breaks (some) irq handling on AVR32

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:	Tue, 14 Apr 2009 15:46:48 +1000
From:	Ben Nizette <bn@...sdigital.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: [REGRESSION] threaded interrupt handler support breaks (some) irq
	handling on AVR32

[cc'ing *correct* lkml address]

After pulling in Linus' latest this morning, a tap on the touchscreen of
my AVR32-based board caused the system to hang hard.  It's an ads7843
touchscreen controller driven by drivers/input/touchscreen/ads7846.c -
the tap triggers a pen-down IRQ.  Note that I made a small mod to that
driver; due to limitations of the AVR32's gpio interrupt controller I
have to do

@@ -1129,7 +1129,7 @@ static int __devinit ads7846_probe(struct spi_device
*spi)

        ts->last_msg = m;

-       if (request_irq(spi->irq, ads7846_irq, IRQF_TRIGGER_FALLING,
+       if (request_irq(spi->irq, ads7846_irq, IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
                        spi->dev.driver->name, ts)) {
                dev_dbg(&spi->dev, "irq %d busy?\n", spi->irq);
                err = -EBUSY;

This doesn't effect the driver operation as the irq handler checks the
logic level of the line anyway.

I've bisected the problem to

commit 3aa551c9b4c40018f0e261a178e3d25478dc04a9
Author: Thomas Gleixner <tglx@...utronix.de>
Date:   Mon Mar 23 18:28:15 2009 +0100

    genirq: add threaded interrupt handler support

    Add support for threaded interrupt handlers:

Because this doesn't revert cleanly I did the bisection again just to be
sure and it came out the same.

Just before the hang,
~ # cat /proc/interrupts
           CPU0
  0:         42      intc  avr32_comparator
  1:          0      intc  atmel_lcdfb
  2:          1      intc  dw_dmac
  4:          4      intc  atmel_spi.1
  9:        555      intc  ttyS0
 21:          0      intc  rtc
 22:      34037      intc  tc_clkevt
 24:          0      intc  atmel_pwm
 25:       2439      intc  eth0
 28:        156      intc  atmel_mci.0
 31:          0      intc  atmel_usba_udc
131:          0      gpio  ads7846

Note it's that very last line which, when triggered, causes the hang.
As you can see, it's the only one connected through the gpio interrupt
chip.

No sysrq action is possible because of the limited kinds of terminals I
can attach to this board.

Given the limited scope for debug (no logs or sysrq output available) I
can't think exactly what more I can tell you to help you get to the
bottom of it.  I'll do whatever I can though, it's perfectly repeatable.

Thanks,
	--Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/