From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10379 Path: news.gmane.org!.POSTED!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: sysconf(_SC_ARG_MAX) broken in musl. Date: Sun, 14 Aug 2016 15:41:40 -0500 Message-ID: <1524ba55-d337-e8a2-070a-ac554328fdf0@landley.net> References: <20160810203602.GA15995@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1471207322 26468 195.159.176.226 (14 Aug 2016 20:42:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 14 Aug 2016 20:42:02 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 Cc: musl@lists.openwall.com To: Alexander Monakov , Rich Felker Original-X-From: musl-return-10392-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 14 22:41:58 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 1bZ2EH-0006ej-5j for gllmg-musl@m.gmane.org; Sun, 14 Aug 2016 22:41:57 +0200 Original-Received: (qmail 17459 invoked by uid 550); 14 Aug 2016 20:41:56 -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 17438 invoked from network); 14 Aug 2016 20:41:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=landley-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=/u+aSgY/MEeSe5xOKiyFtoVOUyD9hsV99Pwsmx0MEQ0=; b=cH8L6M33Dv+dLxNJC4PMvgWJUCt/qP5yMINjADxXgN0GK0caSxwFCrfyyNDUvuksgJ hhxiWmoWc4qYUR0XdLJQBwjTPb+ybzS/eWYn2d3Gte5j53rOt5aPUZtQsgOYP84/gqml uM1iOkUYmW7t2AV8iQB0lCWI4Lc4Y7N4nCoBIIt/kHQWk8Pn8Rh5u4COfP0jA30YDOMI vQf07CuDAA+S+cn7MXtahnJ2KOwblM0P4snpBpwhzZaBgF4yWxqUOgBe0wBqOhLjcHjK iDO/JK2fpht/6e1evSN4UhgD/IHbYtoTDVVdGLbRKQSDyx5JLQht5ZwIjvbqtnxEWinf Ow7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/u+aSgY/MEeSe5xOKiyFtoVOUyD9hsV99Pwsmx0MEQ0=; b=V9dOiwv4pzbUqLj/r2NLEjj8Cyhav5+qzm1fhYkrjTqHxh19zGI0CNNwUn4NDJnitm tMisMOLXwPGn7UPa2oRyCq5phlu5R1e4ITBT37hxX7EYCCYvEsgXTMKA3u4okXUfpIAs d6Q1qpBxpqfSrT6dFsLsaOeaSUMY/uK0EErBiLtMkhuO4x4s2YXvyHQCqofxT/VYwyEH mgYhsVU4jcBxFaOt7puHEEwAGkQKaY+qHfAChSAP2ZDWCMrnqZIBMWayePcWY6znsJYM H3uJfhxY2T30dj6CRyhl4vjRM4DyF8c5Ig7zpxRMN6bTg6ovtTRrgrnXVwYXSWU7B8l+ Ak/w== X-Gm-Message-State: AEkoous2l1KB4zjWF8OyMn0a586FPDLGwI/DPi6rEcesqQQvB3jtXLsKM6iyJXV1qg6oiA== X-Received: by 10.98.66.209 with SMTP id h78mr47891983pfd.11.1471207303372; Sun, 14 Aug 2016 13:41:43 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:10379 Archived-At: 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