Date: Mon, 3 Nov 2003 02:50:20 -0800 (PST) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/58803: kern.argmax isn't changeable even at boot [PATCH] Message-ID: <200311031050.hA3AoKeh089936@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/58803; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: Per Hedeland <per@hedeland.org> Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/58803: kern.argmax isn't changeable even at boot [PATCH] Date: Mon, 3 Nov 2003 21:39:45 +1100 (EST) On Sun, 2 Nov 2003, Per Hedeland wrote: > Bruce Evans <bde@zeta.org.au> wrote: > > ... > >Traditionally hardwired constants cannot usefully be replaced by > >tunables without removing the hardwired constants. Otherwise all the > >users of the hardwired constants get wrong values if the tunables are > >actually used. > > Yes, though from a pragmatic point of view I would still think that as > long as this doesn't cause malfunction, it would be preferable to > breaking existing code that would still function with a constant but > incorrect definition. > ... > So, would the patch be acceptable if it also > > a) Fixed the usage of ARG_MAX in the source tree > b) Made the constant definition be equal to _POSIX_ARG_MAX > c) Prevented setting the tunable lower than _POSIX_ARG_MAX > > ? Removing the definition altogether would of course be just as simple > as b), That would be enough for me, except don't do (b) (leave ARG_MAX with its current value which is larger than _POSIX_ARG_MAX until most or all ports are fixed). Fixing all ports is too much to expect from anyone. Many things in the tree already use only sysconf(_SC_ARG_MAX). The most interesting exceptions are glob(3) (libc/gen/glob.c) and sh(1). glob() just uses ARG_MAX, and sh(1) doesn't use any of glob(), ARG_MAX or sysconf(). > I just feel that it would cause unnecessary breakage. And, what > about NCARGS? NCARGS should have gone away when ARG_MAX became standard, so it should be easier to remove now. NCARGS is used mainly in tcsh. tcsh has ifdefs to use sysconf() if neither NCARGS nor ARG_MAX exists, but they are poorly implemented and just define NCARGS in terms of sysconf() so all the references to NCARGS in tcsh become slow. BTW, I've thought a bit of removing the ARG_MAX limit almost completely. Premptive kernels should prevent denial of service attacks in the time domain the would result from processing almost infinitely args in a non-preemptible execve() call. But a limit on space is still needed, since the execve() wants to kmem_alloc() the space and kernel memory is limited. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311031050.hA3AoKeh089936>