[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 14 Aug 2016 15:41:40 -0500
From: Rob Landley <rob@...dley.net>
To: Alexander Monakov <amonakov@...ras.ru>, Rich Felker <dalias@...ifal.cx>
Cc: musl@...ts.openwall.com
Subject: Re: Re: sysconf(_SC_ARG_MAX) broken in musl.
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
