linux-kernel - Re: Possible race in request_irq() (__setup

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] [day] [month] [year] [list]

Message-ID: <4FBFB237.50007@gmail.com>
Date:	Fri, 25 May 2012 09:24:23 -0700
From:	David Daney <ddaney.cavm@...il.com>
To:	Alexander Sverdlin <asv@...go.com>
CC:	Thomas Gleixner <tglx@...utronix.de>,
	David Daney <ddaney@...iumnetworks.com>,
	Venkat Subbiah <venkat.subbiah@...ium.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Possible race in request_irq() (__setup_irq())

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/