Return to BSD News archive
Xref: sserve comp.unix.bsd:4014 comp.bugs.4bsd:1895 Path: sserve!manuel!munnari.oz.au!uunet!mcsun!Germany.EU.net!tools!ws From: ws@tools.de (Wolfgang Solfrank) Newsgroups: comp.unix.bsd,comp.bugs.4bsd Subject: Re: 386BSD kernel bugs w/fixes Message-ID: <WS.92Aug20191554@kurt.tools.de> Date: 20 Aug 92 17:15:54 GMT References: <1992Aug20.105712.26856@agora.uucp> Sender: news@tools.de Followup-To: comp.unix.bsd Organization: TooLs GmbH, Bonn, Germany Lines: 30 Nntp-Posting-Host: kurt.tools.de In-reply-to: davidg@agora.rain.com's message of 20 Aug 92 10:57:12 GMT While I didn't check the other fixes, at least point 4 is incorrect. In article <1992Aug20.105712.26856@agora.uucp> davidg@agora.rain.com (David Greenman) writes: 4) The virtual memory system has a bug that will prevent a process from growing in its virtual size greater than 6MB data/stack. This is caused by the incorrect process limit being checked in /sys/vm/ vm_unix.c. As they are defined in /sys/i386/include/vmparam.h, the constants DFLDSIZ and DFLSSIZ specify the initial limit (the limit when the process is created in execve()) for a process. The constants MAXTSIZ and MAXSSIZ specify the maximum that a process can grow. These constants are copied into process zero's proc-> p_limit[] and are used as a prototype for all processes. rlim_cur contains DFLDSIZ/DFLSSIZ, and rlim_max contains MAXDSIZ/MAXSSIZ. rlim_max should therefore be used to limit the process's virtual size growth. However, the check is against rlim_cur. The fix is to change the check to rlim_max. One might also note that 6MB for DFLDSIZ/DFLSSIZ in vmparam.h is very low and should be increased to something more reasonable. Most vendors specify an initial limit of 32MB. The behavior of 386BSD is correct. All limits are always checked against the current limits (rlim_cur). That's the purpose of these variables. The maximum limits (rlim_max) are only there for limiting the normal user's ability to increase the limits. These are checked when you try to increase the current limit (see setrlimit(2)). Only the superuser can increase these. -- ws@tools.de (Wolfgang Solfrank, TooLs GmbH) +49-228-985800