Re: Posssible bug in kernel/irq/handle.c

[Linus Torvalds <torvalds@osdl.org>]

On Wed, 9 Nov 2005, Benjamin Herrenschmidt wrote:
> 
> Hrm... yah, it should... still, I find that a bit fragile.
> 
> > So I think the code is correct. It has certainly worked for years on x86 
> > (and it got serious debugging, since we had some rather nasty and subtle 
> > issues with edge-triggered APIC interrupts that just get lost if they are 
> > disabled at the controller).
> 
> Well, we have a "funny" case with some pSeries... the firmware may
> enable interrupts behind our back, and expects us to call a firmware
> "try to handle that interrupt" kind of call when we get one we don't
> handle. That is, either all the handlers returned IRQ_NONE or there is
> no action. I'm not sure how to do that with the current code without
> having our own __do_IRQ() which I'd rather avoid...

Well, I don't think it would be _wrong_ to change the IRQ_INPROGRESS 
handling to work so that it's usabel for PPC.

Some of it may actually be purely historical: I have this dim memory that 
we may have used IRQ_INPROGRESS for the irq autodetection originally (it 
now uses the IRQ_WAITING flag for that).

So I was really only arguing for it not being actively buggy the way it is 
now - which is not to say that we can't change it to be friendlier to 
whatever your needs are.

Be vewy vewy caweful when changing that code, though. If you end up with a 
patch, please try to give it some nice stress-testing (both on ppc and 
x86), and then post it for comments, ok? Maybe the arch mailing list and 
Ingo (who else has touched that logic?)

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