[PATCH] Use malloca instead alloca

[Florian Weimer]

On 01/09/2013 05:44 PM, Rich Felker wrote:
> On Wed, Jan 09, 2013 at 05:09:23PM +0100, Florian Weimer wrote:
>> On 01/08/2013 09:41 PM, Ondřej Bílka wrote:
>>
>>> One technical issue is if we want to use STACKINFO_BP_DEF. It would make
>>> getting base pointer more portable but must be added to each function
>>> that uses __libc_use_alloca.
>>
>> I'm interested in extending GCC to provide a better alloca,
>> including one that can fail.  Parts of the split stacks support
>> might reusable for obtaining the stack boundary.
>
> We spent a bit of time analyzing whether split stack is useful on the
> musl list, and concluded that for the most part it's just harmful. For
> 64-bit systems, it has no significant advantages over just allocating
> large stacks and letting the kernel do overcommit.

This really depends on your environment.  Some systems have lightweight 
processes with a baseline cost of less than a page.  I agree that if you 
need more than a page for other reasons, split stacks are probably not 
that interesting.

Anyway, to clarify, I'm not interested in enabling split stacks per se. 
  But the split stack support records the stack boundary in a TLS 
variable, and __builtin_alloca could use that to check (reasonably 
cheaply, both in terms of code size and run-time cost) that the 
allocation attempt doesn't exceed the available space.  It would be a 
bit like -fcheck-stack, but hopefully much cheaper because the stack 
banging logic isn't needed.

>> I'm a bit skeptical about the whole alloca-if-we-have-room concept.
>> We must make sure that we keep sufficient stack space for further
>> operation.  But I'm not sure how to determine the magic number of
>> bytes to reserve.
>
> I agree entirely. It strikes me as just as misguided as when
> application developers ask "how to I check how much memory the system
> has so I can hoarde it all?" If you're making what you use
> proportional to what's available rather than to what you need, you're
> doing something wrong.

Good analogy.

> Honestly, my recommendation would be to ban use of alloca and VLA
> entirely and replace them by small fixed-size arrays (like 256-1024
> bytes depending on the expected usage), and simply call malloc when
> the need is greater than the fixed size. This makes the free logic
> easy (if (ptr!=fixed_buf) free(ptr);) and reduces the code size and
> improves performance in the common cases (since the compiler can
> generate better, simpler code when it does not need to do the
> frame-pointer-like logic for managing dynamic-size allocations on the
> stack.

As long as there's alloca, developers will use it.  It's quite popular 
even in new code.  I suspect it's not just the performance aspect, the 
implicit free() is likely a factor, too.

I'm not sure if we can change this preference, at least until we have 
conservative garbage collection as part of libc (so that heap allocation 
and stack allocation are equally simple).

-- 
Florian Weimer / Red Hat Product Security Team