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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 28 Oct 2012 18:34:50 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Roland Stigge <stigge@...com.de>
cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	paul.gortmaker@...driver.com, benh@...nel.crashing.org
Subject: Re: irq_set_chained_handler() called too early for hwirq to be
 initialized

On Sun, 28 Oct 2012, Roland Stigge wrote:
> 
> consider arch/arm/mach-lpc32xx/irq.c: irq_set_chained_handler() is
> called at a point where it accesses
> irq_to_desc(IRQ_LPC32XX_SUB2IRQ)->irq_data.hwirq but which is not yet
> initialized.

None of the functions which are called inside of
irq_set_chained_handler() touches desc->irq_data.hwirq.

So what are you talking about?

I just had a look into that lpc32xx irq code. At the end of
lpc32xx_init_irq():

        irq_base = irq_alloc_descs(-1, 0, NR_IRQS, 0);
        if (irq_base < 0) {
                pr_warn("Cannot allocate irq_descs, assuming pre-allocated\n");
                irq_base = 0;
        }

That's just hilarious.

Of course are the interrupts preallocated, simply because
machine_desc->nr_irqs is 0 and therefor the ARM core code allocates
NR_IRQS irq descriptors in the early setup way before
lpc32xx_init_irq() is called.

If those interrupts would not be preallocated, then the code would
fail to initialize any interrupt at all. And of course nothing would
notice as all function calls to set_irq_* do not check the return
value.

That brilliant thing came in via commit f5c42271 (ARM: LPC32xx: Device
tree support). I have no idea from where you copied that and why you
thought putting it at the end of the init function would be a good
idea.

Though, that has nothing todo with your problem description above.

Thanks,

	tglx
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ