This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] posix: Remove dynamic memory allocation from execl{e,p}
- From: Florian Weimer <fweimer at redhat dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 29 Jan 2016 14:58:23 +0100
- Subject: Re: [PATCH] posix: Remove dynamic memory allocation from execl{e,p}
- Authentication-results: sourceware.org; auth=none
- References: <1454075599-2304-1-git-send-email-adhemerval dot zanella at linaro dot org>
On 01/29/2016 02:53 PM, Adhemerval Zanella wrote:
> GLIBC execl{e,p} implementation might use malloc if the total number of
> arguments exceeds initial assumption size (1024). This might lead to
> issues in two situations:
>
> 1. execl/execle is stated to be async-signal-safe by POSIX [1]. However
> if it is used in a signal handler with a large argument set (that
> may call malloc internally) and the resulting call fails, it might
> lead malloc in the program in a bad state.
>
> 2. If the functions are used in a vfork/clone(VFORK) situation it also
> might break internal malloc state from parent.
>
> This patch fixes it by using stack allocation instead. It fixes
> BZ#19534.
I would rather see a variant of struct scratch_buffer which uses mmap
for the fallback allocation, and use it here, rather than imposing
arbitrary limits. It's not clear to me at all if __MAX_ALLOCA_CUTOFF is
a reasonable value inside a signal handler.
Florian