From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10370 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: sysconf(_SC_ARG_MAX) broken in musl. Date: Wed, 10 Aug 2016 16:36:02 -0400 Message-ID: <20160810203602.GA15995@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1470861392 31630 195.159.176.226 (10 Aug 2016 20:36:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 10 Aug 2016 20:36:32 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: musl@lists.openwall.com To: Rob Landley Original-X-From: musl-return-10383-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 10 22:36:27 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1bXaEk-000856-Uj for gllmg-musl@m.gmane.org; Wed, 10 Aug 2016 22:36:27 +0200 Original-Received: (qmail 28053 invoked by uid 550); 10 Aug 2016 20:36:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 28010 invoked from network); 10 Aug 2016 20:36:21 -0000 Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:10370 Archived-At: 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