stack bloat after stackprotector changes

[Tejun Heo]

Hello,

Eric Sandeen wrote:
> Tejun Heo wrote:
>> Eric Sandeen wrote:
>>> It seems that after:
>>>
>>> commit 5d707e9c8ef2a3596ed5c975c6ff05cec890c2b4
>>> Author: Tejun Heo <tj at kernel.org>
>>> 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.  :-(

Thanks.

-- 
tejun