Re: [patch 2/3] genirq: warn about IRQF_SHARED|IRQF_DISABLED at theright place

[Thomas Gleixner]

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@xxxxxxxxxxxxx> wrote:
> 
> > On Thu, 11 Mar 2010, akpm@xxxxxxxxxxxxxxxxxxxx wrote:
> > 
> > > From: Uwe Kleine-K?nig <u.kleine-koenig@xxxxxxxxxxxxxx>
> > > 
> > > 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/