From tegge@itea.ntnu.no  Sun Oct 13 17:12:40 1996
Received: from istind.itea.unit.no (istind.itea.unit.no [129.241.190.12])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA12886
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 13 Oct 1996 17:12:07 -0700 (PDT)
Received: from skarven.itea.ntnu.no (tegge@skarven.itea.ntnu.no [129.241.190.13]) by istind.itea.unit.no (8.6.12/1.9.AHJ) with ESMTP id AAA26269 for <FreeBSD-gnats-submit@freebsd.org>; Mon, 14 Oct 1996 00:11:50 GMT
Received: (from tegge@localhost) by skarven.itea.ntnu.no (8.7.6/8.7.3) id CAA03168; Mon, 14 Oct 1996 02:11:49 +0200 (MET DST)
Message-Id: <199610140011.CAA03168@skarven.itea.ntnu.no>
Date: Mon, 14 Oct 1996 02:11:49 +0200 (MET DST)
From: Tor Egge <tegge@itea.ntnu.no>
Reply-To: tegge@itea.ntnu.no
To: FreeBSD-gnats-submit@freebsd.org
Subject: syslimits.h does not allow overriding default value of ARG_MAX
X-Send-Pr-Version: 3.2

>Number:         1791
>Category:       kern
>Synopsis:       syslimits.h does not allow overriding default value of ARG_MAX
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sun Oct 13 17:20:01 PDT 1996
>Closed-Date:    Sat Nov 17 23:23:23 UTC 2007
>Last-Modified:  Sat Nov 17 23:23:23 UTC 2007
>Originator:     Tor Egge
>Release:        FreeBSD 2.2-CURRENT i386
>Organization:
Norwegian University of Science and Technology, Trondheim, Norway

>Environment:

FreeBSD skarven.itea.ntnu.no 2.2-CURRENT FreeBSD 2.2-CURRENT #0: Fri Oct 11 23:58:42  1996     root@skarven.itea.ntnu.no:/usr/src/sys/compile/SKARVEN  i386

>Description:

	It is not possible to specify an alternative value of ARG_MAX
	in the kernel config file, since /usr/src/sys/sys/syslimits.h 
	defines ARG_MAX even if it was defined.

>How-To-Repeat:

	Compile a kernel where one line in the kernel config file says

	options         ARG_MAX=262144

>Fix:

	Only define ARG_MAX if it is not already defined.

Index: syslimits.h
===================================================================
RCS file: /export/ftpsearch3/cvs/src/sys/sys/syslimits.h,v
retrieving revision 1.6
diff -c -r1.6 syslimits.h
*** syslimits.h	1994/12/03 17:36:37	1.6
--- syslimits.h	1996/10/11 21:28:38
***************
*** 37,43 ****
--- 37,45 ----
  #ifndef _SYS_SYSLIMITS_H_
  #define _SYS_SYSLIMITS_H_
  
+ #ifndef ARG_MAX
  #define	ARG_MAX			65536	/* max bytes for an exec function */
+ #endif
  #ifndef CHILD_MAX
  #define	CHILD_MAX		   40	/* max simultaneous processes */
  #endif

>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: FreeBSD-gnats-submit@FreeBSD.org, tegge@itea.ntnu.no
Cc:  Subject: Re: misc/1791: syslimits.h does not allow overriding default value of ARG_MAX
Date: Mon, 14 Oct 1996 18:37:04 +1000

 >	It is not possible to specify an alternative value of ARG_MAX
 >	in the kernel config file, since /usr/src/sys/sys/syslimits.h 
 >	defines ARG_MAX even if it was defined.
 
 This isn't a bug.  Defining ARG_MAX in <limits.h> advertises to
 applications that ARG_MAX is a constant with the given value.  The
 only correct way to change it is to change the header and recompile
 all applications that depend on it (ps, xargs and who-knows-what
 else).
 
 The best way to fix the problem is to remove the definition of
 ARG_MAX from <limits.h> and then fix everything that (bogusly)
 depends on it.  Non-bogus dependencies on it look like this:
 
 #ifdef ARG_MAX
 	char buf[ARG_MAX];
 #else
 	long arg_max;
 	char *buf;
 
 	arg_max = sysconf(_SC_ARG_MAX);
 	if (arg_max == -1)
 		barf("sysconf");
 	st_arg_max = (size_t)arg_max;
 	if (st_arg_max != arg_max);
 		barf("unrepresentable arg_max");
 	buf = malloc(st_arg_max);
 	if (buf == NULL)
 		barf("malloc");
 #endif
 
 The kernel should use some other name for ARG_MAX to avoid confusion.
 
 I have fixed most the corresponding problems for OPEN_MAX and CHILD_MAX.
 They are now named PROC0_RLIMIT_NOFILE and PROC0_RLIMIT_NPROC in my
 kernel sources.
 
 Bruce

From: Tor Egge <Tor.Egge@idt.ntnu.no>
To: bde@zeta.org.au
Cc: FreeBSD-gnats-submit@freebsd.org, tegge@itea.ntnu.no
Subject: Re: misc/1791: syslimits.h does not allow overriding default value of ARG_MAX
Date: Mon, 14 Oct 1996 15:33:36 +0200

 > >	It is not possible to specify an alternative value of ARG_MAX
 > >	in the kernel config file, since /usr/src/sys/sys/syslimits.h 
 > >	defines ARG_MAX even if it was defined.
 > 
 > This isn't a bug.  Defining ARG_MAX in <limits.h> advertises to
 > applications that ARG_MAX is a constant with the given value.  The
 > only correct way to change it is to change the header and recompile
 > all applications that depend on it (ps, xargs and who-knows-what
 > else).
 > 
 > The best way to fix the problem is to remove the definition of
 > ARG_MAX from <limits.h> and then fix everything that (bogusly)
 > depends on it.
 > 
 
 Correct.
 
 A short grep for ARG_MAX in the non-kernel part of the FreeBSD source tree
 shows only a few occurences:
 
 ./bin/ps/fmt.c: static char buf[ARG_MAX];               /* XXX */
 ./contrib/gcc/config/i386/xm-sco.h:/* SCO has a very small ARG_MAX.  */
 ./contrib/gcc/config/i386/xm-sysv4.h:/* Univel, at least, has a small ARG_MAX.  Defining this is harmless
 ./contrib/gcc/gcc.c:   only important to return 0 if the host machine has a small ARG_MAX
 ./usr.bin/xargs/xargs.c:         * POSIX.2 limits the exec line length to ARG_MAX - 2K.  Running that
 ./usr.bin/xargs/xargs.c:         * caused some E2BIG errors, so it was changed to ARG_MAX - 4K.  Given
 ./usr.bin/xargs/xargs.c:         *       (ARG_MAX - 4K - LENGTH(utility + arguments)) / 2.
 ./usr.bin/xargs/xargs.c:        nline = ARG_MAX - 4 * 1024;
 
 
 Only the ps and xargs parts are interesting. 
 
 ps is already broken, e.g. compile this program and run it in the
 background, then run ps with xwww as arguments while this program is
 still running. Immediate buffer overflow in shquote due to the buffer
 being only ARG_MAX in size, instead of 4*ARG_MAX+1. 
 
 
 	#include <sys/types.h>
 	#include <stdio.h>
 	#include <vis.h>
 	#include <errno.h>
 
 	int main(int argc,char **argv)
 	{
 	  char arg[30000];
 	  char arg2[600000];
 	
 	  strcpy(arg,"sleep 10 # ");
 	  memset(arg+strlen(arg),'\201',sizeof(arg)-strlen(arg));
 	  arg[sizeof(arg)-1]=0;
 	 
 	  strvis(arg2,arg,VIS_NL | VIS_CSTYLE);
 	  printf("len is %d\n",strlen(arg2));
 	  execl("/bin/sh","sh","-c",arg,0);
 	  printf("FAILED, errno=%d\n",errno);
 	}
 
 
 xargs having a too low (i.e. too conservative) value for ARG_MAX does not
 normally cause any problems. It only reduces performance.
 
 - Tor Egge
State-Changed-From-To: open->suspended 
State-Changed-By: phk 
State-Changed-When: Sat May 23 02:36:01 PDT 1998 
State-Changed-Why:  
now we just need somebody to do it... 

From: Joseph Koshy <jkoshy>
To: freebsd-gnats-submit@freebsd.org, tegge
Cc: bde, jkoshy
Subject: Re: misc/1791: syslimits.h does not allow overriding default value of ARG_MAX
Date: Wed, 17 Jun 1998 06:07:31 -0700 (PDT)

 `xargs' and `ps' have been changed to remove compile time dependencies
 on the value of ARG_MAX.  The PR is being kept open because, as BDE points
 out, the right fix is to remove ARG_MAX, CHILD_MAX, OPEN_MAX etc
 from the header files completely.
 
 Koshy
Responsible-Changed-From-To: freebsd-bugs->tegge 
Responsible-Changed-By: asmodai 
Responsible-Changed-When: Mon Jan 10 09:43:48 PST 2000 
Responsible-Changed-Why:  
Allow Tor to close his own PR's. 
Responsible-Changed-From-To: tegge->freebsd-bugs 
Responsible-Changed-By: kmacy 
Responsible-Changed-When: Sat Nov 17 23:21:36 UTC 2007 
Responsible-Changed-Why:  

Submitter says it should not have been assigned  
to him seeing as his solution was not accepted. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=1791 
State-Changed-From-To: suspended->closed 
State-Changed-By: kmacy 
State-Changed-When: Sat Nov 17 23:22:51 UTC 2007 
State-Changed-Why:  

Timeout, not likely to be fixed and less of an issue now that the default is 64k. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=1791 
>Unformatted:
Tor, what are your plans for this?
