Date: Wed, 10 Aug 2016 16:36:02 -0400 From: Rich Felker <dalias@...ifal.cx> To: Rob Landley <rob@...dley.net> Cc: musl@...ts.openwall.com Subject: Re: sysconf(_SC_ARG_MAX) broken in 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
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.