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: <873ajfoy1a.fsf@basil.nowhere.org>
Date:	Thu, 02 Oct 2008 16:46:09 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Arjan van de Veen <arjan@...radead.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Jon Masters <jonathan@...masters.org>,
	Sven Dietrich <sdietrich@...e.de>
Subject: Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

Thomas Gleixner <tglx@...utronix.de> writes:
>
>  - move long running handlers out of the hard interrupt context

I'm not sure I'm really looking forward to this brave new world
of very long running interrupt handlers. e.g. what do you
do for example when some handler blocks for a very long time?

>  - improved debugability of the kernel: faulty handlers do not take
>    down the system.

I had an old patch to handle this without threaded interrupts. 

What normally happens is when a interrupt oopses it tries to kill the
idle process which panics.  My fix was to just restart another idle
process instead of panicing.

But back then it was rejected by Linus with the argument that
a crashing interrupt handler will typically hold some lock
and the next time the interrupt happens it will deadlock on that
lock. 

Has that changed with your threaded interrupts? 

If it has changed I suspect the restart idle change could
be made to work to be equivalent in debuggability.

> Comments, reviews, flames as usual.

To be honest my opinion is that it will encourage badly written interrupt
code longer term.

-Andi

-- 
ak@...ux.intel.com
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ