From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932511AbXCGGor (ORCPT ); Wed, 7 Mar 2007 01:44:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932706AbXCGGor (ORCPT ); Wed, 7 Mar 2007 01:44:47 -0500 Received: from rgminet01.oracle.com ([148.87.113.118]:38076 "EHLO rgminet01.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932739AbXCGGoq (ORCPT ); Wed, 7 Mar 2007 01:44:46 -0500 Date: Tue, 6 Mar 2007 22:44:23 -0800 From: Bill Irwin To: Arjan van de Ven Cc: Bill Irwin , Hugh Dickins , Chuck Ebbert , Andi Kleen , linux-kernel Subject: Re: Wanted: simple, safe x86 stack overflow detection Message-ID: <20070307064423.GH18774@holomorphy.com> Mail-Followup-To: Bill Irwin , Arjan van de Ven , Hugh Dickins , Chuck Ebbert , Andi Kleen , linux-kernel References: <45E5913D.3080505@redhat.com> <20070228204144.GA32316@one.firstfloor.org> <20070304015031.GA4224@holomorphy.com> <45EDBA1B.8050007@redhat.com> <20070306203432.GD18774@holomorphy.com> <1173241715.3236.16.camel@laptopd505.fenrus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1173241715.3236.16.camel@laptopd505.fenrus.org> User-Agent: Mutt/1.5.11 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At some point in the past, I wrote: >> I'm certainly in favor of the move; IRQ stacks could be made >> rather deep and cheaply at that. I may get around to writing it this >> week if no one else does it first. On Tue, Mar 06, 2007 at 08:28:35PM -0800, Arjan van de Ven wrote: > the irq stacks aren't the problem; RH at some point accidentally shipped > a kernel with 4k *shared* irq/user context stack and even that gave > almost no issues. > irq's really shouldn't actually nest; it's bad for just about everything > to do that (but that's another story, I would *love* to get rid of the > "enable irqs" thing in the x86 irq path, it hurts just about anything in > reality) What do you see as the obstacle to eliminating nested IRQ's? It doesn't seem so far out to test for being on the interrupt stack and defer the call to do_IRQ() until after the currently-running instance of do_IRQ() has returned, or to move to per-irq stacks modulo special arrangements for the per-cpu IRQ's. Or did you have other methods in mind? -- wli