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: <1271316940.32749.61.camel@laptop>
Date:	Thu, 15 Apr 2010 09:35:40 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	mingo@...hat.com, hpa@...or.com, acme@...hat.com,
	linux-kernel@...r.kernel.org, andi@...stfloor.org,
	alan@...rguk.ukuu.org.uk, davem@...emloft.net, torvalds@...l.org,
	gregkh@...e.de, tglx@...utronix.de, mingo@...e.hu
Cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:irq/core] genirq: Run irq handlers with interrupts
 disabled

On Tue, 2010-04-13 at 19:33 +0000, tip-bot for Ingo Molnar wrote:
> Commit-ID:  e58aa3d2d0cc01ad8d6f7f640a0670433f794922
> Gitweb:     http://git.kernel.org/tip/e58aa3d2d0cc01ad8d6f7f640a0670433f794922
> Author:     Ingo Molnar <mingo@...e.hu>
> AuthorDate: Fri, 26 Mar 2010 00:06:51 +0000
> Committer:  Thomas Gleixner <tglx@...utronix.de>
> CommitDate: Tue, 13 Apr 2010 16:36:40 +0200
> 
> genirq: Run irq handlers with interrupts disabled
> 
> Running interrupt handlers with interrupts enabled can cause stack
> overflows. That has been observed with multiqueue NICs delivering all
> their interrupts to a single core. We might band aid that somehow by
> checking the interrupt stacks, but the real safe fix is to run the irq
> handlers with interrupts disabled.
> 
> Drivers for whacky hardware still can reenable them in the handler
> itself, if the need arises. (They do already due to lockdep)
> 
> The risk of doing this is rather low:
> 
>  - lockdep already enforces this
>  - CONFIG_NOHZ has shaken out the drivers which relied on jiffies updates
>  - time keeping is not longer sensitive to the timer interrupt being delayed

Clearly I don't mind this, but shouldn't we at least first convert the
known problematic drivers to an alternative strategy?

IDE-PIO, that one ancient NIC etc..

> ---
>  kernel/irq/handle.c |    3 ---
>  1 files changed, 0 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
> index 76d5a67..27e5c69 100644
> --- a/kernel/irq/handle.c
> +++ b/kernel/irq/handle.c
> @@ -370,9 +370,6 @@ irqreturn_t handle_IRQ_event(unsigned int irq, struct irqaction *action)
>  	irqreturn_t ret, retval = IRQ_NONE;
>  	unsigned int status = 0;
>  
> -	if (!(action->flags & IRQF_DISABLED))
> -		local_irq_enable_in_hardirq();
> -
>  	do {
>  		trace_irq_handler_entry(irq, action);
>  		ret = action->handler(irq, action->dev_id);



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