home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / bsd / 4506 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  2.2 KB
  1. Xref: sparky comp.unix.bsd:4506 comp.bugs.4bsd:207
  2. Path: sparky!uunet!mcsun!Germany.EU.net!tools!ws
  3. From: ws@tools.de (Wolfgang Solfrank)
  4. Newsgroups: comp.unix.bsd,comp.bugs.4bsd
  5. Subject: Re: 386BSD kernel bugs w/fixes
  6. Message-ID: <WS.92Aug20191554@kurt.tools.de>
  7. Date: 20 Aug 92 17:15:54 GMT
  8. References: <1992Aug20.105712.26856@agora.uucp>
  9. Sender: news@tools.de
  10. Followup-To: comp.unix.bsd
  11. Organization: TooLs GmbH, Bonn, Germany
  12. Lines: 30
  13. Nntp-Posting-Host: kurt.tools.de
  14. In-reply-to: davidg@agora.rain.com's message of 20 Aug 92 10:57:12 GMT
  15.  
  16.  
  17. While I didn't check the other fixes, at least point 4 is incorrect.
  18.  
  19. In article <1992Aug20.105712.26856@agora.uucp> davidg@agora.rain.com (David Greenman) writes:
  20.  
  21.    4) The virtual memory system has a bug that will prevent a process from
  22.        growing in its virtual size greater than 6MB data/stack. This is
  23.        caused by the incorrect process limit being checked in /sys/vm/
  24.        vm_unix.c. As they are defined in /sys/i386/include/vmparam.h,
  25.        the constants DFLDSIZ and DFLSSIZ specify the initial limit (the
  26.        limit when the process is created in execve()) for a process. The
  27.        constants MAXTSIZ and MAXSSIZ specify the maximum that a process
  28.        can grow. These constants are copied into process zero's proc->
  29.        p_limit[] and are used as a prototype for all processes. rlim_cur
  30.        contains DFLDSIZ/DFLSSIZ, and rlim_max contains MAXDSIZ/MAXSSIZ.
  31.        rlim_max should therefore be used to limit the process's virtual
  32.        size growth. However, the check is against rlim_cur. The fix is
  33.        to change the check to rlim_max. One might also note that 6MB for
  34.        DFLDSIZ/DFLSSIZ in vmparam.h is very low and should be increased
  35.        to something more reasonable. Most vendors specify an initial
  36.        limit of 32MB.
  37.  
  38. The behavior of 386BSD is correct. All limits are always checked against
  39. the current limits (rlim_cur). That's the purpose of these variables.
  40. The maximum limits (rlim_max) are only there for limiting the normal user's
  41. ability to increase the limits. These are checked when you try to increase
  42. the current limit (see setrlimit(2)). Only the superuser can increase these.
  43.  
  44. --
  45. ws@tools.de     (Wolfgang Solfrank, TooLs GmbH) +49-228-985800
  46.