Re: malloca, freea are not thread-safe

[Ondřej Bílka]

On Wed, Jan 10, 2018 at 03:02:17PM +0100, Florian Weimer wrote:
> The mmalloca function used to implement malloca accesses a static
> global array without synchronization:
> 
> #define HASH_TABLE_SIZE 257
> static void * mmalloca_results[HASH_TABLE_SIZE];
> …
> mmalloca (size_t n)
> {
> …
>     /* Enter p into the hash table.  */
>           slot = (uintptr_t) p % HASH_TABLE_SIZE;
>           h->next = mmalloca_results[slot];
>           mmalloca_results[slot] = p;
> 
> freea also causes valgrind warnings because it contains an
> out-of-bounds access.  This is very undesirable because it will
> cause programmers to miss real bugs.
> 
> This code has been copied into libunistring and results in a thread
> safety hazard there.
> 
> Thanks,
> Florian
First let S = sa_alignment_max;

This could be done faster without hash table by making alloca result
aligned to 2 * S and malloc ones not aligned to 2 * S by adding some padding.

It would make check on free simpler. For allocation its fastest with
__builtin_alloca_with_align(x, 2 * sa_alignment_max)

Without that it more depends on how much gcc messes up alloca and if it
could optimize x & c1 & c2 to x & (c1 & c2) for constants c1 and c2.

With downward growing stack a=alloca(n) could be done as (%rsp - n) & (~(S-1))
then we align it with ret = (a & (~(2*S-1))) + 2 * S