linux-kernel - Re: [GIT PATCH] more Driver core patches for 2.6.19

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

Date:	Thu, 14 Dec 2006 09:32:22 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Greg KH <gregkh@...e.de>, Andrew Morton <akpm@...l.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19

On Thu, 14 Dec 2006, Jan Engelhardt wrote:
> 
> Rather than IRQ_HANDLED, it should have been: remove this irq handler 
> from the irq handlers for irq number N, so that it does not get called 
> again until userspace has acked it.

Wrongo.

That just means that the _handler_ won't be called.

But the irq still stays active, and if it's shared, ALL THE OTHER HANDLERS 
FOR THAT INTERRUPT will be called. 

Over and over again. Forever. Because the machine won't be making any 
progress, and the user-level code (which might know how to shut it up) 
won't ever be called, because the machine is busy just doing interrupt 
delivery all the time.

> See, maybe I don't have enough clue yet to exactly figure out why you 
> say it does not work. However, this is how simple people see it 8)

You may be a bit simple. But I think it's more polite to call you 
"special". Or maybe just not very used to how hardware works.

Btw, this is not something theoretical. We used to have this particular 
problem _all_ the time with PCMCIA back when we weren't as good at 
interrupt routing. You'd insert a PCMCIA card, and the machine just hung. 
Hard.

And the reason was that it would send an irq, but we were expecting it on 
another interrupt. But if it showed up on something that was shared, you'd 
have a hung machine, because you'd just have the (say) ethernet driver 
saying "not for me", and returning. And obviously not able to actually 
shut it up, so when we returned from the interrupt handler, the interrupt 
happened immediately again.

So this really isn't theoretical. It's a very common failure schenario for 
mishandled interrupts. In fact, exactly because it's so common, these days 
we have all this special logic in the generic interrupt layer that 
notices, and shuts them up entirely (but does so by disabling _all_ the 
devices on that interrupt, so when this happens, you might well lose your 
disk driver or somethign else).

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