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?
> 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...)
> 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