Re: [linux-next:master 12891/13017] mm/slub.c:2396:1: warning: '___slab_alloc' uses dynamic stack allocation

["Andreas Krebbel1" <Andreas.Krebbel@de.ibm.com>]

[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]

mschwid2@linux.vnet.ibm.com 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-


[-- Attachment #2: Type: text/html, Size: 3040 bytes --]