Re: Possible race in request_irq() (__setup_irq())

From: David Daney
Date: Fri May 25 2012 - 12:24:23 EST


On 05/25/2012 07:01 AM, Alexander Sverdlin wrote:
Hello Thomas, David, Venkat,

On 05/16/2012 03:44 PM, Thomas Gleixner wrote:
Your irq is using handle_percpu_irq() as the flow handler.

handle_percpu_irq() is a special flow handler which does not take the
irq descriptor lock for performance reasons. It's a single interrupt
number which has a percpu dev_id and can be handled on all cores in
parallel.

The interrupts need to be marked as such and requested with
request_percpu_irq(). Those interrupts are either marked as
NOAUTOENABLE or set up by the low level setup code, which runs on the
boot cpu with interrupt enabled.

Those interrupts are marked as percpu and can only be requested with
request_percpu_irq().


Could someone comment please, why exactly this happens in current linux-next for Octeon:

In arch/mips/cavium-octeon/octeon-irq.c MBOX IRQs are set up to be handled by handle_percpu_irq():

static void __init octeon_irq_init_ciu(void)
{
...
octeon_irq_set_ciu_mapping(OCTEON_IRQ_MBOX0, 0, 32, chip_mbox, handle_percpu_irq);
octeon_irq_set_ciu_mapping(OCTEON_IRQ_MBOX1, 0, 33, chip_mbox, handle_percpu_irq);

But in arch/mips/cavium-octeon/smp.c it's requested as normal IRQ:

void octeon_prepare_cpus(unsigned int max_cpus)
{
...
if (request_irq(OCTEON_IRQ_MBOX0, mailbox_interrupt,
IRQF_PERCPU | IRQF_NO_THREAD, "SMP-IPI",
mailbox_interrupt)) {
panic("Cannot request_irq(OCTEON_IRQ_MBOX0)");
}

Is it a bug, or some kind of special case?


Probably a bug. But it works, so it has never been an issue.

Patches to bring this code more in line with current Linux irq orthodoxy would receive prompt review. Especially if there were an explanation of some problem they were fixing.

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