mschwid2@xxxxxxxxxxxxxxxxxx wrote on 11/13/2015 12:52:00
PM:
> > This patch doesn't add any dynamic stack allocations. The
fact that
> > slub.c already had a bunch of these warnings makes me suspect
that it's
> > happening in one of the s390 headers?
>
> That looks like a false positive to me. I can not find any function
that does
> a dynamic allocation and the generated code creates a stack frame
with a
> constant size. A bit odd is the fact that the stack frame is create
in two
> steps, e.g. deactivate_slab:
>
> a632: b9 04 00 ef
lgr %r14,%r15
> a636: a7 fb ff 50
aghi %r15,-176 # first
176 bytes
> a63a: b9 04 00 bf
lgr %r11,%r15
> a63e: e3 e0 f0 98 00 24
stg %r14,152(%r15)
> a644: e3 10 f0 98 00 04
lg %r1,152(%r15)
> a64a: a7 fb ff 30
aghi %r15,-208 #
> another 208 bytes
> a64e: e3 30 b0 e8 00 24
stg %r3,232(%r11)
> a654: e3 40 b0 d8 00 24
stg %r4,216(%r11)
>
> Strange. Andreas can you make something of this?
Hi Martin,
this appears to be the result of aligning struct page
to more than 8 bytes and putting it onto the stack - wich is only 8 bytes
aligned. The compiler has to perform runtime alignment to achieve
that. It allocates memory using *alloca* and does the math with the returned
pointer. Our dynamic stack allocation option basically only checks if there
is an alloca user.
We have added that -mwarn-dynamicstack option because
our runtime check (-mstack-guard) is only able to deal with the static
stack allocations. So with dynamic stack allocations you might still overwrite
stuff without the runtime stack guard being able to catch it. So in one
regard the warning is correct since there in fact is a stack allocation
which will not be covered by the stack guard. One the other hand the additional
stack allocation is done with a constant value so it is not really dynamic
and the warning message is not really helpful. Perhaps we should emit warnings
whenever there are stack allocations present which aren't covered by the
stack guard? Or should we silently ignore such a case?
-Andreas-