[Top] [All Lists]

Re: stack bloat after stackprotector changes

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: stack bloat after stackprotector changes
From: Tejun Heo <tj@xxxxxxxxxx>
Date: Wed, 07 Oct 2009 10:32:57 +0900
Cc: xfs mailing list <xfs@xxxxxxxxxxx>
In-reply-to: <4ACB50C1.80702@xxxxxxxxxxx>
References: <4ACA5EB0.4010707@xxxxxxxxxxx> <4ACADB74.5090508@xxxxxxxxxx> <4ACB50C1.80702@xxxxxxxxxxx>
User-agent: Thunderbird (X11/20090817)

Eric Sandeen wrote:
> Tejun Heo wrote:
>> Eric Sandeen wrote:
>>> It seems that after:
>>> commit 5d707e9c8ef2a3596ed5c975c6ff05cec890c2b4
>>> Author: Tejun Heo <tj@xxxxxxxxxx>
>>> Date:   Mon Feb 9 22:17:39 2009 +0900
>>>     stackprotector: update make rules
>>> xfs stack usage jumped up a fair bit;
>>> Not a lot in each case but could be significant as it accumulates.
>>> I'm not familiar w/ the gcc stack protector feature; would this be an
>>> expected result?
>> Yeah, it adds a bit of stack usage per each function call and around
>> arrays which seem like they could overflow, so the behavior is
>> expected and I can see it can be a problem with function call depth
>> that deep.  Has it caused actual stack overflow?
>> Thanks.
> It's hard to point at one thing and say "that caused it" but I did
> overflow (or come very close to it - this one was within 8 bytes).
> Add 20 byte or so to each of 65 calls and it starts to matter I guess.
> Granted, xfs is being piggy too (as are some of the more common
> functions in the callchain - do_sync_write and write_cache_pages at 320
> bytes each...)
> -Eric
>          Depth    Size   Location    (65 entries)
>          -----    ----   --------
>    0)     7280      80   check_object+0x6c/0x1d3

Yeap, that's pretty darn close.

But the thing is that stackprotector is a feature which consumes
certain amount of stack space, so there I'm afraid really isn't a way
around that other than trying to diet the piggies or enlarging the
stack.  :-(



<Prev in Thread] Current Thread [Next in Thread>