DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=HYCXuOibLQui27ndcmF5kT/CsFEB6GfinXOLhpaWedoKPByO1DqJVUxvVH/XPOO/RrNZgaKz+nNbk605CBkyihK+fkS5BMLvSDBBY35oytCMGGgSiXrxdi5jm8Pb3JlUivj79XaH4N1hAcpr34YRl73LAC/gi+rSRuitnjIZs/Y=
Message-ID: <9a8748490708291553j4c21bdf0ueae0b51c99c8190a@mail.gmail.com>
Date: Thu, 30 Aug 2007 00:53:56 +0200
From: "Jesper Juhl" <jesper.juhl@gmail.com>
To: "Eric Sandeen" <sandeen@redhat.com>
Subject: Re: 4KSTACKS + DEBUG_STACKOVERFLOW harmful
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
In-Reply-To: <46D5F462.9010401@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <46D5F462.9010401@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2497
Lines: 56

On 30/08/2007, Eric Sandeen <sandeen@redhat.com> wrote:
> Noticed today that the combination of 4KSTACKS and DEBUG_STACKOVERFLOW
> config options is a bit deadly.
>
> DEBUG_STACKOVERFLOW warns in do_IRQ if we're within THREAD_SIZE/8 of the
> end of useable stack space, or 512 bytes on a 4k stack.
>
> If we are, then it goes down the dump_stack path, which uses most, if
> not all, of the remaining stack, thereby turning a well-intentioned
> warning into a full-blown catastrophe.
>
...
>
> 448 bytes to tell us that we're within 512 bytes (or less) of certain
> doom... and I think there's call overhead on top of that?
>
> The large stack usage in those 2 functions is due to big char arrays, of
> size KSYM_NAME_LEN (128 bytes) and KSYM_SYMBOL_LEN (223 bytes).
>
> IOW, the stack warning effectively reduces useful stack left in our itty
> bitty 4k stacks by over 10%.
>
> Any suggestions for ways around this?  The warning is somewhat helpful,
> and I guess the obvious option is to lighten up the dump_stack path, but
> it's still effectively reducing precious available stack space by some
> amount.
>
A first step could be to allocate those two char arrays with kmalloc()
instead of on the stack, but then I guess that dump_stack() gets
called from places where we may not really want to be calling
kmalloc(). I guess we could allocate the buffers earlier (like at boot
time) and store pointers somewhere where dump stack can get to them
later when it needs them.


> With CONFIG_DEBUG_STACK_USAGE, we could print at oops time: "oh, and by
> the way, you blew your stack" if there is no zeroed stack space left, as
> a post-mortem.  Even without that option, I think we could still check
> whether the *current* %esp at oops time has gone too far?  But if we
> blew the stack, returned, and *then* oops, I think it'd be hard to know
> without the DEBUG_STACK_USAGE option that we ran out of room.
>

We could also simply have it warn at a higher limit, like 1024 bytes
instead of 512. But I guess then we would get too many false positives
and make it less useful.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html
-
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/