Messages in this thread |  | | | Date | Wed, 21 Oct 2009 16:22:31 -0400 | | From | Chuck Ebbert <> | | Subject | Re: XFS stack overhead |
| |
On Wed, 21 Oct 2009 14:21:54 -0500 Eric Sandeen <sandeen@redhat.com> wrote:
> > Also, the posting apparently mixes 'stack overhead' with 'runtime > > overhead'. > > right, that's why I asked, I'm not sure if stackprotector has runtime > overhead as well. >
A bigger stack causes runtime overhead too because it increases the cache footprint of the workload.
For the function I looked at the insn overhead was substantial:
On entry: ffffffff8113ffa0: 48 83 ec 10 sub $0x10,%rsp ... ffffffff8113ffa9: 65 48 8b 04 25 28 00 mov %gs:0x28,%rax ffffffff8113ffb0: 00 00 ffffffff8113ffb2: 48 89 45 f8 mov %rax,-0x8(%rbp) On exit: ffffffff81140000: 48 8b 55 f8 mov -0x8(%rbp),%rdx ffffffff81140004: 65 48 33 14 25 28 00 xor %gs:0x28,%rdx ffffffff8114000b: 00 00 ffffffff8114000d: 74 13 je ffffffff81140022 <mem_cgroup_get_reclaim_stat_from_page+0x86> ... ffffffff8114001d: e8 ef 42 f2 ff callq ffffffff81064311 <__stack_chk_fail> So that's 37 extra bytes of code: 1 subtract, 4 reg/mem moves, an xor and a conditional jump that always get executed -- on every function call.
And all that, in this case, for a function that doesn't even have any on-stack variables and can hardly be expected to be vulnerable to stack-smashing attacks.
|  |