Re: sysconf(_SC_ARG_MAX) broken in musl.

Re: sysconf(_SC_ARG_MAX) broken in musl.

[Rich Felker]

On Wed, Aug 10, 2016 at 02:28:22PM -0500, Rob Landley wrote:
> I draw your attention to the end of:
> 
> http://lists.landley.net/pipermail/toybox-landley.net/2016-August/008592.html
> 
> tl;dr: in 2007 linux switched ARG_MAX to 1/4 the stack size ulimit (with
> a minimum of 131072 and no I dunno what happens if you try to launch a
> program with lots of argument data when stack size is < 131072).
> 
> Current glibc sysconf() checks the getrlimit() value and returns 1/4 of
> it (or 131072). Musl is returning the hardwired 131072 value from before
> 2007.

I'm aware of that change in the kernel that allows larger
argument/environment contingent on resource limits, but I'm not clear
that there's any good reason for ARG_MAX/sysconf(_SC_ARG_MAX) to
reflect this. My understanding of the normal usage pattern for ARG_MAX
is that programs (e.g. xargs, find) that might be passing a large
number of arguments to external programs use it to ensure that the
exec will not fail due to sending too many at a time. For this purpose
using the fixed 128k limit works perfectly well and reduces memory
usage and the risk of failure to exec due to ENOMEM.

Has anyone else looked into the issue enough to have a good opinion on
it, or at least additional information that would add to discussion?

Rich

Re: Re: sysconf(_SC_ARG_MAX) broken in musl.

[Alexander Monakov]

On Wed, 10 Aug 2016, Rich Felker wrote:
> Has anyone else looked into the issue enough to have a good opinion on
> it, or at least additional information that would add to discussion?

To provide a data point, I've been told that userspace QEmu used to limit the
cumulative args length in a more restrictive way than the kernel (1/4th stack
limit). The observed failure mode was this: xargs running under qemu-user would
build the command line according to what glibc thought would be accepted by the
syscall (based on large stack size), but then the syscall would fail because
qemu-user wouldn't process that many args.

I understand this is not much, since qemu-user is unreliable in other ways, and
this particular issue has been fixed in QEmu regardless, but still I think it
contributes to the general point. Is the concern that 128KB is too low to be
usable? My understanding is that _SC_ARG_MAX is not broken in musl (contrary to
what the subject says), just conservative (in a healthy way in this case imho).

Alexander

Re: Re: sysconf(_SC_ARG_MAX) broken in musl.

[Rob Landley]

On 08/14/2016 03:20 PM, Alexander Monakov wrote:
> On Wed, 10 Aug 2016, Rich Felker wrote:
>> Has anyone else looked into the issue enough to have a good opinion on
>> it, or at least additional information that would add to discussion?
> 
> To provide a data point, I've been told that userspace QEmu used to limit the
> cumulative args length in a more restrictive way than the kernel (1/4th stack
> limit). The observed failure mode was this: xargs running under qemu-user would
> build the command line according to what glibc thought would be accepted by the
> syscall (based on large stack size), but then the syscall would fail because
> qemu-user wouldn't process that many args.
> 
> I understand this is not much, since qemu-user is unreliable in other ways, and
> this particular issue has been fixed in QEmu regardless, but still I think it
> contributes to the general point. Is the concern that 128KB is too low to be
> usable? My understanding is that _SC_ARG_MAX is not broken in musl (contrary to
> what the subject says), just conservative (in a healthy way in this case imho).

The reason for sysconf() instead of a #defined limit is so you can query
the system to get the actual value, which may vary at runtime. (And in
this case, does, since ulimit can modify it arbitrarily without even
requiring special access.)

What happens if your stack size is smaller than 131072? (Not
stacksize/4, but stacksize total?) I haven't tried, but a quick glance
looks like Bad Things. And on nommu systems, that may actually come up.

Rob

Re: Re: sysconf(_SC_ARG_MAX) broken in musl.

[Alexander Monakov]

On Sun, 14 Aug 2016, Rob Landley wrote:
> What happens if your stack size is smaller than 131072? (Not
> stacksize/4, but stacksize total?) I haven't tried, but a quick glance
> looks like Bad Things. And on nommu systems, that may actually come up.

From reading the kernel source, I'm not sure what happens on nommu, but on mmu,
from what I see, what's left for the program is rlimit, minus argv/env/auxv size,
minus variable amount lost due to stack base randomization. In particular, yes,
if rlimit_stack is below 128K and cumulative argv size is high, execve can fail.

So is the concern that the reported sysconf(_SC_ARG_MAX) value is not useful
when stack limit is low? But to know how many arguments you can pass in this
highly constrained situation, you'd have to get rlimit, subtract environment
size (and not even the current environment size, but the environment you're
passing via execve), subtract the worst-case randomization loss, and finally
subtract the amount of stack the invoked program is going to need.

Alexander