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

Date:	Sat, 13 Mar 2010 01:59:50 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	u.kleine-koenig@...gutronix.de, 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


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.

Thanks,

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