Re: [patch, -rc5-mm1] locking validator: special rule: 8390.c disable_irq()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2006-05-31 at 23:56 +0200, Arjan van de Ven wrote:
> On Wed, 2006-05-31 at 23:47 +0200, Ingo Molnar wrote:
> > * Arjan van de Ven <[email protected]> wrote:
> > > yeah since misrouted irqs will cause the kernel do disable irqs 'at 
> > > random' more or less .. for which the handlers now would become 
> > > unreachable which isn't good.
> > 
> > couldnt most of these problems be avoided by tracking whether a handler 
> > _ever_ returned a success status? That means that irqpoll could safely 
> > poll handlers for which we know that they somehow arent yet matched up 
> > to any IRQ line?
> 
> I suspect the real solution is to have a
> 
> disable_irq_handler(irq, handler) 
> 
> function which does 2 things
> 1) disable the irq at the hardware level
> 2) mark the handler as "don't call me"
> 
> it matches the semantics here; what these drivers want is 1) not get an
> irq handler called and 2) not get an irq flood

(Sorry for coming in late, but I'm slowly catching up with LKML)

Couldn't it be possible to have the misrouted irq function mark the
DISABLED_IRQ handlers as IRQ_PENDING?  Then have the enable_irq that
actually enables the irq to call the handlers with interrupts disabled
if the IRQ_PENDING is set?

-- Steve


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux