linux-kernel - Re: Unhandled IRQs on AMD E-450

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]

Message-ID: <4F9E89E6.7070508@ladisch.de>
Date:	Mon, 30 Apr 2012 14:47:34 +0200
From:	Clemens Ladisch <clemens@...isch.de>
To:	Jeroen Van den Keybus <jeroen.vandenkeybus@...il.com>
CC:	Josh Boyer <jwboyer@...il.com>,
	Borislav Petkov <borislav.petkov@....com>, andymatei@...il.com,
	"Huang, Shane" <Shane.Huang@....com>,
	Borislav Petkov <bp@...64.org>, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Unhandled IRQs on AMD E-450

Jeroen Van den Keybus wrote:
>> Why 5?  This threshold is likely to be too low; fast consecutive interrupts
>> can easily happen more often with a very busy device, while an actual stuck
>> interrupt will call the handler in an endless loop and very quickly result
>> in many thousands of calls.
>
> Well, 5 works fine on any machine I have tested so far. I'd like to
> keep this number as low as possible in case a genuine stuck interrupt
> is encountered. Computers are powerful, but I'm reluctant to spill
> cycles and power.

A stuck interrupt is the consequence of a bug, there is no need to
compromise just to optimize for this situation (especially as even with
your broken hardware and the patch, stuck interrupts happen no more than
once per second).

> Also, on an unshared interrupt line, unhandled IRQs should never
> happen in succession.

Indeed.  But this is because pending interrupts are not queued but simply
noted with a boolean.

> ... broken hardware, i.e. hardware emitting MSIs without getting
> acknowledgement). Am I right ?

Level-triggered interrupts would need acknowledgements to deactivate
the interrupt line, but MSIs do not.  Hardware that is designed to
take advantage of this indeed works this way; this avoids the need for
any MMIO accesses in the interrupt handler.


Regards,
Clemens
--
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/