Re: [patch 2/3] genirq: warn about IRQF_SHARED|IRQF_DISABLED atthe right place

[Uwe Kleine-König]

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@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.
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/