linux-kernel - Re: [patch 2/3] genirq: warn about IRQF_SHARED|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] [day] [month] [year] [list]

Date:	Mon, 15 Mar 2010 09:38:51 +0100
From:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	a.p.zijlstra@...llo.nl, andrea.gallo@...ricsson.com,
	dbrownell@...rs.sourceforge.net, eric.y.miao@...il.com,
	hugh.dickins@...cali.co.uk, jamie@...reable.org,
	John Stultz <johnstul@...ibm.com>, linux@...mer.net,
	nico@...vell.com, Rusty Russell <rusty@...tcorp.com.au>,
	Greg KH <greg@...ah.com>, David Miller <davem@...emloft.net>
Subject: Re: [patch 2/3] genirq: warn about IRQF_SHARED|IRQF_DISABLED at
	the right place

Hello,

On Sat, Mar 13, 2010 at 01:59:50AM +0100, Thomas Gleixner wrote:
> 
> Back to LKML and Cc'ed a few more folks
> 
> On Fri, 12 Mar 2010, Andrew Morton wrote:
> 
> > On Sat, 13 Mar 2010 00:32:28 +0100 (CET)
> > Thomas Gleixner <tglx@...utronix.de> wrote:
> > 
> > > On Thu, 11 Mar 2010, akpm@...ux-foundation.org wrote:
> > > 
> > > > From: Uwe Kleine-K?nig <u.kleine-koenig@...gutronix.de>
> > > > 
> > > > For shared irqs IRQF_DISABLED is only guaranteed for the first handler. 
> > > > So only warn starting at the second registration.
> > > > 
> > > > The warning is moved to __setup_irq having the additional benefit of
> > > > catching actions registered using setup_irq not only register_irq.
> > > > 
> > > > This doesn't fix the cases where setup order is wrong but it should report
> > > > the broken cases more reliably.
> > > 
> > > Please drop this. It's just useless shuffling off code for no real
> > > benefit.
> > > 
> > 
> > I think that warning on the second-registered IRQ was probably a
> > mistake.  Because registering just the first IRQF_DISABLED handler only
> > works by luck, and is vlunerable to someone else adding a handler later.
> > 
> > But extending the warning so that it also covers setup_irq() seems
> > sensible enough.
> 
> Well, this is a crappy concept anyway and it would be way more
> worthwhile to figure out why we need IRQF_DISABLED at all.
> 
> An irq handler should just run always with irqs disabled. The flag is
> just there to deal with crappy drivers which take hundreds of
> microseconds or more in their interrupt service routines. 
> 
> hint: IDE, USB ...
> 
> I'm simply refusing to apply patches which just shuffle code around to
> warn about obscure use cases instead of tackling the real problem of
> long running irq handlers which prevent us to get rid of IRQF_DISABLED
> and just run all interrupt handlers with irqs disabled. Getting rid of
> that would also simplify stuff which needs to be aware of reentrancy
> now.
The intention for my patch is a problem that have occured at least twice
in the past on the linux-arm-kernel mailing list.  On at91 the timer irq
is shared with some peripherals and we got reports that on these
machines the timer core BUGged because irq were not disabled.  Up to now
the reporters didn't help to debug that to the end.  So I'd consider it
nice to make it easy for the next person running into that problem now
that we know that there is a problem in that area.

I still think the patch is worthwhile as I think we're not getting rid
of IRQF_DISABLED in the next few release cycles, are we?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
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/