* Re: sysconf(_SC_ARG_MAX) broken in musl. [not found] <bcf8d4b8-aee7-da0e-dffa-0f7cd9fdc30e@landley.net> @ 2016-08-10 20:36 ` Rich Felker 2016-08-14 20:20 ` Alexander Monakov 0 siblings, 1 reply; 4+ messages in thread From: Rich Felker @ 2016-08-10 20:36 UTC (permalink / raw) To: Rob Landley; +Cc: musl 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Re: sysconf(_SC_ARG_MAX) broken in musl. 2016-08-10 20:36 ` sysconf(_SC_ARG_MAX) broken in musl Rich Felker @ 2016-08-14 20:20 ` Alexander Monakov 2016-08-14 20:41 ` Rob Landley 0 siblings, 1 reply; 4+ messages in thread From: Alexander Monakov @ 2016-08-14 20:20 UTC (permalink / raw) To: Rich Felker; +Cc: Rob Landley, musl 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Re: sysconf(_SC_ARG_MAX) broken in musl. 2016-08-14 20:20 ` Alexander Monakov @ 2016-08-14 20:41 ` Rob Landley 2016-08-14 22:11 ` Alexander Monakov 0 siblings, 1 reply; 4+ messages in thread From: Rob Landley @ 2016-08-14 20:41 UTC (permalink / raw) To: Alexander Monakov, Rich Felker; +Cc: 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Re: sysconf(_SC_ARG_MAX) broken in musl. 2016-08-14 20:41 ` Rob Landley @ 2016-08-14 22:11 ` Alexander Monakov 0 siblings, 0 replies; 4+ messages in thread From: Alexander Monakov @ 2016-08-14 22:11 UTC (permalink / raw) To: Rob Landley; +Cc: Rich Felker, musl 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-08-14 22:11 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <bcf8d4b8-aee7-da0e-dffa-0f7cd9fdc30e@landley.net> 2016-08-10 20:36 ` sysconf(_SC_ARG_MAX) broken in musl Rich Felker 2016-08-14 20:20 ` Alexander Monakov 2016-08-14 20:41 ` Rob Landley 2016-08-14 22:11 ` Alexander Monakov
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).