linux-kernel - Re: [PATCH 20/62] sparc: irq: Remove IRQF

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]

Message-Id: <20110907.135110.2069876782156753239.davem@davemloft.net>
Date:	Wed, 07 Sep 2011 13:51:10 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	tglx@...utronix.de
Cc:	yong.zhang0@...il.com, linux-kernel@...r.kernel.org, mingo@...e.hu,
	joe@...ches.com, sparclinux@...r.kernel.org
Subject: Re: [PATCH 20/62] sparc: irq: Remove IRQF_DISABLED

From: Thomas Gleixner <tglx@...utronix.de>
Date: Wed, 7 Sep 2011 19:33:52 +0200 (CEST)

> 
> 
> On Wed, 7 Sep 2011, Thomas Gleixner wrote:
> 
>> On Wed, 7 Sep 2011, David Miller wrote:
>> 
>> > From: Yong Zhang <yong.zhang0@...il.com>
>> > Date: Wed,  7 Sep 2011 16:10:17 +0800
>> > 
>> > > This flag is a NOOP and can be removed now.
>> > > 
>> > > Signed-off-by: Yong Zhang <yong.zhang0@...il.com>
>> > 
>> > How are things working now, if that is the case?
>> > 
>> > Specifically in the ldc_bind() case, we're passing iRQF_DISABLED here
>> > so that the IRQ is not turned on when we request the IRQ, we later do
>> > enable_irq() on these after we've take the spinlock in this function.
>> > 
>> > The IRQ cannot be allowed to be delivered between the request_irq()
>> > call and the enable_irq() calls.
>> > 
>> > This sequence is necessary to deal with some lock ordering issues.
>> 
>> IRQF_DISABLED was telling the core code that the interrupt must run
>> with interrupts disabled. As we enforced running all handlers with
>> interrupts disabled the flag is meaningless. It was defined as 0
>> anyway.
>> 
>> What you need to prevent that request_irq() enables the interrupt
>> unconditionally, is to set IRQ_NOAUTOEN on the interrupt, which can't
>> be handed in to request_irq(). You want to call
>> 
>>    irq_set_status_flags(irq, IRQ_NOAUTOEN);
>> 
>> for that irq. That tells request_irq() to leave the interrupt disabled
>> and you have to explicitely enable it. That has not changed since we
>> generalized the irq core code back in 2006.
> 
> If that's an issue, then we can create an IRQF_NOAUTOEN flag, which
> can be handed into request_irq().

Actually, the issue is that I wanted the interrupt handler to run with
interrupts disabled.

We had big problems when openning thousands of virtual network
devices, each with their own unique IRQ, and pointed all at the same
cpu, and we'd get IRQ stack overflows.

See commit c58543c869606532c2382f027d6466f4672ea756

So this change to make IRQF_DISABLED a nop has reintroduced this bug.
--
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/