From jgreco@anacreon.sol.net  Thu Aug 22 12:59:13 1996
Received: from anacreon.sol.net (anacreon.sol.net [206.55.64.116])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA11689
          for <FreeBSD-gnats-submit@freebsd.org>; Thu, 22 Aug 1996 12:57:52 -0700 (PDT)
Received: (from root@localhost) by anacreon.sol.net (8.6.12/8.6.12) id OAA23038; Thu, 22 Aug 1996 14:57:39 -0500
Message-Id: <199608221957.OAA23038@anacreon.sol.net>
Date: Thu, 22 Aug 1996 14:57:39 -0500
From: jgreco@ns.sol.net
Reply-To: jgreco@ns.sol.net
To: FreeBSD-gnats-submit@freebsd.org
Subject: VM Crash with massive numbers of mmap's
X-Send-Pr-Version: 3.2

>Number:         1533
>Category:       kern
>Synopsis:       Machine can be panicked by a userland program.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    dillon
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Aug 22 13:00:02 PDT 1996
>Closed-Date:    Tue Mar 13 23:33:00 PST 2001
>Last-Modified:  Tue Mar 13 23:35:05 PST 2001
>Originator:     Joe Greco
>Release:        FreeBSD 2.1-STABLE i386
>Organization:
sol.net Network Services
>Environment:

	Pentium 133, ASUS Triton-II motherboard, 192MB RAM, 
	3 x NCR 810 SCSI controllers, 15 Hawk 1GB drives plus 2 Barra 4G's,
	SMC EtherPower 10/100

	Kernel configuration:

Local modifications:	DK_NDRIVE --> 32
			MSG_BSIZE --> (16384 - 3 * sizeof(unsigned int))

sysctl -w kern.update=300

/sys/i386/conf/NEWSREADER_DB:

#
# NEWSREADER_DB -- Generic machine with WD/AHx/NCR/BTx family disks
#
#	$Id: NEWSREADER_DB,v 1.46.2.18 1996/07/16 08:53:04 davidg Exp $
#

machine		"i386"
#cpu		"I386_CPU"
cpu		"I486_CPU"
cpu		"I586_CPU"
ident		"NEWSREADER_DB"
maxusers	256

options         "MAXMEM=262720"         #real memory  = 67698688 (16528 pages)
                                        #+192MB = 256MB

options		MATH_EMULATE		#Support for x87 emulation
options		INET			#InterNETworking
options		FFS			#Berkeley Fast Filesystem
options		NFS			#Network Filesystem
options		MSDOSFS			#MSDOS Filesystem
options		"CD9660"		#ISO 9660 Filesystem
options		PROCFS			#Process filesystem
options		"COMPAT_43"		#Compatible with BSD 4.3
options		"SCSI_DELAY=5"		#Be pessimistic about Joe SCSI device
options		BOUNCE_BUFFERS		#include support for DMA bounce buffers
options		UCONSOLE		#Allow users to grab the console

options               "CHILD_MAX=512"
options               "OPEN_MAX=256"
#options               "NMBCLUSTERS=512"

options		SYSVSHM
options		SYSVSEM
options		SYSVMSG

config		kernel	root on wd0 

controller	isa0
controller	eisa0
controller	pci0

controller	fdc0	at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
disk		fd0	at fdc0 drive 0
#disk		fd1	at fdc0 drive 1
#tape		ft0	at fdc0 drive 2

#controller	wdc0	at isa? port "IO_WD1" bio irq 14 vector wdintr
#disk		wd0	at wdc0 drive 0
#disk		wd1	at wdc0 drive 1

#controller	wdc1	at isa? port "IO_WD2" bio irq 15 vector wdintr
#disk		wd2	at wdc1 drive 0
#disk		wd3	at wdc1 drive 1

#options         ATAPI   #Enable ATAPI support for IDE bus
#device          wcd0    #IDE CD-ROM

controller	ncr0
controller	ncr1
controller	ncr2
controller	ahc0
controller	ahc1

#controller	bt0	at isa? port "IO_BT0" bio irq ? vector bt_isa_intr
#controller	uha0	at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr
#controller	aha0	at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr
#controller	aic0    at isa? port 0x340 bio irq 11 vector aicintr
#controller	nca0	at isa? port 0x1f88 bio irq 10 vector ncaintr
#controller	nca1	at isa? port 0x350 bio irq 5 vector ncaintr
#controller	sea0	at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr

controller      scbus0  at ncr0

disk  sd0 at scbus0     target 0 unit 0
disk  sd1 at scbus0     target 1 unit 0
disk  sd2 at scbus0     target 2 unit 0
disk  sd3 at scbus0     target 3 unit 0
disk  sd4 at scbus0     target 4 unit 0
disk  sd5 at scbus0     target 5 unit 0
disk  sd6 at scbus0     target 6 unit 0

controller      scbus1  at ncr1

disk sd10 at scbus1     target 0 unit 0
disk sd11 at scbus1     target 1 unit 0
disk sd12 at scbus1     target 2 unit 0
disk sd13 at scbus1     target 3 unit 0
disk sd14 at scbus1     target 4 unit 0
disk sd15 at scbus1     target 5 unit 0
disk sd16 at scbus1     target 6 unit 0

controller      scbus2  at ncr2

disk sd20 at scbus2     target 0 unit 0
disk sd21 at scbus2     target 1 unit 0
disk sd22 at scbus2     target 2 unit 0
disk sd23 at scbus2     target 3 unit 0
disk sd24 at scbus2     target 4 unit 0
disk sd25 at scbus2     target 5 unit 0
disk sd26 at scbus2     target 6 unit 0

#device		sd0

device		st0

#device		cd0	#Only need one of these, the code dynamically grows

#device		wt0	at isa? port 0x300 bio irq 5 drq 1 vector wtintr
#device		mcd0	at isa? port 0x300 bio irq 10 vector mcdintr

#controller	matcd0	at isa? port 0x230 bio

#device		scd0	at isa? port 0x230 bio

# syscons is the default console driver, resembling an SCO console
device		sc0	at isa? port "IO_KBD" tty irq 1 vector scintr
# Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver
#device		vt0	at isa? port "IO_KBD" tty irq 1 vector pcrint
#options		"PCVT_FREEBSD=210"	# pcvt running on FreeBSD 2.1
#options		XSERVER			# include code for XFree86
# If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines
#options		PCVT_SCANSET=2		# IBM keyboards are non-std

# Mandatory, don't remove
device		npx0	at isa? port "IO_NPX" irq 13 vector npxintr

#
# Laptop support (see LINT for more options)
#
#device		apm0    at isa?		# Advanced Power Management
#options		APM_BROKEN_STATCLOCK	# Workaround some buggy APM BIOS

device		sio0	at isa? port "IO_COM1" tty irq 4 vector siointr
device		sio1	at isa? port "IO_COM2" tty irq 3 vector siointr
device		sio2	at isa? port "IO_COM3" tty irq 5 vector siointr
device		sio3	at isa? port "IO_COM4" tty irq 9 vector siointr

device		lpt0	at isa? port? tty irq 7 vector lptintr
device		lpt1	at isa? port? tty
#device		mse0	at isa? port 0x23c tty irq 5 vector mseintr
device		psm0	at isa? disable port "IO_KBD" conflicts tty irq 12 vector psmintr

# Order is important here due to intrusive probes, do *not* alphabetize
# this list of network interfaces until the probes have been fixed.
# Right now it appears that the ie0 must be probed before ep0. See
# revision 1.20 of this file.
device de0
#device fxp0
#device vx0
device ed0 at isa? port 0x280 net irq  5 iomem 0xd8000 vector edintr
device ed1 at isa? port 0x300 net irq  5 iomem 0xd8000 vector edintr
#device ie0 at isa? port 0x360 net irq  7 iomem 0xd0000 vector ieintr
#device ep0 at isa? port 0x300 net irq 10 vector epintr
#device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr
#device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr
#device lnc0 at isa? port 0x280 net irq 10 drq 0 vector lncintr
#device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr
#device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr

pseudo-device	ccd	12	#Concatenated disk driver

pseudo-device	loop
pseudo-device	ether
pseudo-device	log
pseudo-device	sl	1
# ijppp uses tun instead of ppp device
pseudo-device	ppp	1
pseudo-device	tun	1
pseudo-device	pty	16
pseudo-device	gzip		# Exec gzipped a.out's
pseudo-device	vn		#Vnode driver (turns a file into a device)
pseudo-device	bpfilter	8	#Berkeley packet filter

>Description:

	Attempting to mmap() thousands of files caused the system to
	reboot or panic (can't tell which, the system is many miles away,
	but dmesg shows no saved data).  It freaked both times I tried it.

	The same program, run under Solaris, eventually quit with an
	ENOMEM error.

>How-To-Repeat:

Program:

#include        <stdio.h>
#include        <sys/types.h>
#include        <sys/stat.h>
#include        <sys/mman.h>
#include        <fcntl.h>

#define         MAX             1048576

caddr_t array[MAX];

int main()
{
        int i = 0;
        int fd;
        char filename[2048];
        struct stat s;
        caddr_t this;

        while (i < MAX) {
                gets(filename);
                if ((fd = open(filename, O_RDONLY, 0)) < 0) {
                        perror(filename);
                        sleep(1);
                } else {
                        if (fstat(fd, &s) < 0) {
                                perror("fstat");
                                sleep(1);
                        } else {
                                this = mmap((caddr_t) 0, s.st_size, PROT_READ,
                                        MAP_PRIVATE, fd, (off_t) 0);
                                if ((int) this == -1) {
                                        perror("mmap");
                                        sleep(1);
                                } else {
                                        array[i++] = this;
                                }
                        }
                        close(fd);
                }
                if (! (i % 512)) {
                        fprintf(stderr, "[%d] .. ", i);
                }
        }
}

I ran this on a news spool, as follows:

daily-bugle% find /news -type f -print | /tmp/a.out
{output output...} [34816] .. [35328] .. [35840] .. [36352] .. [36864] .. [37376] .. [37888] .. [38400] .. [38912] .. [39424] .. [39936] .. [40448] .. [40960] .. [41472] .. [41984] .. [42496] .. {hang}

In another window I was running "vmstat 1 |grep vnodes|grep K" once a second:

       vnodes 16009  2000K   2017K 19661K    17174    0     0  16,128,256
       vnodes 16009  2000K   2017K 19661K    17174    0     0  16,128,256
       vnodes 16009  2000K   2017K 19661K    17174    0     0  16,128,256
       vnodes 16009  2000K   2017K 19661K    17174    0     0  16,128,256
       vnodes 16009  2000K   2017K 19661K    17174    0     0  16,128,256
       vnodes 16009  2000K   2017K 19661K    17174    0     0  16,128,256
       vnodes 16009  2000K   2017K 19661K    17174    0     0  16,128,256
       vnodes 16009  2000K   2017K 19661K    17174    0     0  16,128,256
       vnodes 16009  2000K   2017K 19661K    17174    0     0  16,128,256
       vnodes 16037  2003K   2017K 19661K    17202    0     0  16,128,256
       vnodes 16203  2024K   2024K 19661K    17368    0     0  16,128,256
       vnodes 16347  2042K   2042K 19661K    17512    0     0  16,128,256
       vnodes 16354  2043K   2043K 19661K    17519    0     0  16,128,256
{etc etc}
       vnodes 42315  5288K   5288K 19661K    43480    0     0  16,128,256
       vnodes 42315  5288K   5288K 19661K    43480    0     0  16,128,256
       vnodes 42319  5288K   5288K 19661K    43484    0     0  16,128,256
       vnodes 42320  5288K   5288K 19661K    43485    0     0  16,128,256
       vnodes 42320  5288K   5288K 19661K    43485    0     0  16,128,256
       vnodes 42322  5288K   5288K 19661K    43487    0     0  16,128,256
       vnodes 42324  5289K   5289K 19661K    43489    0     0  16,128,256
       vnodes 42324  5289K   5289K 19661K    43489    0     0  16,128,256
       vnodes 42324  5289K   5289K 19661K    43489    0     0  16,128,256
       vnodes 42324  5289K   5289K 19661K    43489    0     0  16,128,256
       vnodes 42324  5289K   5289K 19661K    43489    0     0  16,128,256
       vnodes 42324  5289K   5289K 19661K    43489    0     0  16,128,256
       vnodes 42447  5304K   5304K 19661K    43612    0     0  16,128,256
       vnodes 42504  5311K   5311K 19661K    43669    0     0  16,128,256
       vnodes 42504  5311K   5311K 19661K    43669    0     0  16,128,256
       vnodes 42900  5361K   5361K 19661K    44065    0     0  16,128,256
{hang}

>Fix:
	
	Don't mmap trillions of files.  :-)  Probably not a good sol'n.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->dyson 
Responsible-Changed-By: wosch 
Responsible-Changed-When: Thu Sep 26 16:57:10 PDT 1996 
Responsible-Changed-Why:  
mmap problem, John's area. 
State-Changed-From-To: open->feedback 
State-Changed-By: phk 
State-Changed-When: Sat May 23 02:31:50 PDT 1998 
State-Changed-Why:  
is this still a problem ? 

From: Kris Kennaway <kkennawa@physics.adelaide.edu.au>
To: freebsd-gnats-submit@freebsd.org, jgreco@anacreon.sol.net, phk@freebsd.org
Cc:  Subject: Re: kern/1533: VM Crash with massive numbers of mmap's
Date: Sat, 28 Nov 1998 22:18:52 +1030 (CST)

 I was browsing through the old PRs and came across this one. Tried running the
 supplied code on my
 
 FreeBSD morden.rebel.net.au 3.0-CURRENT FreeBSD 3.0-CURRENT #11: Fri Nov 27
 15:20:45 CST 1998     kkenn@morden.rebel.net.au:/usr2/src/sys/compile/MORDEN
 i386
 
 machine and it eventually hung, after mmapping about 30k files and reaching
 489MB. The code was run as an unprivileged user, and the first symptom was
 that disk access wasblocking. I had a 'top' running in another xterm, and it
 showed the process hung in the "FFS no" state: processes were continuing to
 run, but nothing was able to talk to the disk. I changed to a virtual console,
 back to X, and the whole machine hung and required a reboot.
 
 So, looks like there's still something going on here..
 
 Kris
 

From: Robert Garrett <eagle@phc.igs.net>
To: freebsd-gnats-submit@freebsd.org, jgreco@ns.sol.net
Cc:  
Subject: Re: kern/1533: Machine can be panicked by a userland program.
Date: Thu, 05 Aug 1999 23:52:52 -0400

 Well This still will shut down a 4.0 - current box as of 05/08/99
 
 Rob
 
 
State-Changed-From-To: feedback->open 
State-Changed-By: sheldonh 
State-Changed-When: Tue Aug 10 04:03:44 PDT 1999 
State-Changed-Why:  
John's left the building. 


Responsible-Changed-From-To: dyson->freebsd-bugs 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Tue Aug 10 04:03:44 PDT 1999 
Responsible-Changed-Why:  
There's been lots of feedback, but only relating to the symptoms, not 
the cause. 
State-Changed-From-To: open->feedback 
State-Changed-By: asmodai 
State-Changed-When: Sat Feb 5 04:55:12 PST 2000 
State-Changed-Why:  
I am expecting (hopefully) some feedback on this from either phk 
or dillon after I ran the test on CURRENT. 

From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>
To: FreeBSD Gnats <freebsd-gnats-submit@freebsd.org>
Cc:  
Subject: Re: kern/1533: Machine can be panicked by a userland program.
Date: Sat, 5 Feb 2000 15:18:01 +0100

 [resend due to hub/builder mail problems]
 
 This PR which details an old mmap() seems to be fixed in CURRENT at
 least, and I suspect Matthew Dillon is guilty for that. =)
 
 My results:
 
 [asmodai@celestial] (17) $ find /usr/src -type f -print | ./a.out 
 warning: this program uses gets(), which is unsafe.
 [512] .. [1024] .. [1536] .. [2048] .. [2560] .. [3072] .. [3584] ..
 [4096] .. [4608] .. [5120] .. [5632] .. [6144] .. [6656] .. [7168] ..
 [7680] .. [8192] .. [8704] .. [9216] .. [9728] .. [10240] .. [10752] ..
 [11264] .. [11776] .. [12288] .. [12800] .. [13312] .. [13824] ..
 [14336] .. [14848] .. [15360] .. [15872] .. [16384] .. [16896] ..
 [17408] .. [17920] .. [18432] .. [18944] .. [19456] .. [19968] ..
 [20480] .. [20992] .. [21504] .. [22016] .. [22528] .. [23040] ..
 [23552] .. [24064] .. [24576] .. [25088] .. [25600] .. [26112] ..
 [26624] .. [27136] .. [27648] .. [28160] .. [28672] .. [29184] ..
 [29696] .. [30208] .. [30720] .. [31232] .. [31744] .. [32256] ..
 [32768] .. [33280] .. [33792] .. [34304] .. [34816] .. [35328] ..
 [35840] .. [36352] .. [36864] .. [37376] .. [37888] .. [38400] ..
 [38912] .. mmap: Cannot allocate memory
 mmap: Cannot allocate memory
 mmap: Cannot allocate memory
 mmap: Cannot allocate memory
 mmap: Cannot allocate memory
 mmap: Cannot allocate memory
 mmap: Cannot allocate memory
 
 ((ad inifitum I guess))
 
 One funny thing is that systat -vmstat reported freevnodes of between
 the 20 and 30 every time, but when mmap was spewing the Cannot allocate
 memory warnings it suddenly rose:
 
 Mem:KB    REAL            VIRTUAL                     VN PAGER  SWAP PAGER
         Tot   Share      Tot    Share    Free         in  out     in  out
 Act    3120     664     5104      680   45400 count
 All   81372    1288  2689648     1472         pages
                                                                  Interrupts
 Proc:r  p  d  s  w    Csw  Trp  Sys  Int  Sof  Flt        cow     100 total
               4         3        14  100    1    1  41624 wire        ata-pci0 i
                                                      5944 act         mux irq18
  0.3%Sys   0.0%Intr  0.0%User  0.0%Nice 99.7%Idl    33788 inact       fdc0 irq6
 |    |    |    |    |    |    |    |    |    |         16 cache       atkbd0 irq
                                                     45384 free        sio0 irq4
                                                           daefr       sio1 irq3
 Namei         Name-cache    Dir-cache                     prcfr   100 clk irq0
     Calls     hits    %     hits    %                     react
                                                           pdwake
                                           zfod            pdpgs
 Disks   ad0   ad4   fd0   md0             ofod            intrn
 KB/t   0.00  0.00  0.00  0.00             %slo-z    10939 buf
 tps       0     0     0     0             tfree         5 dirtybuf
 MB/s   0.00  0.00  0.00  0.00                        8966 desiredvnodes
 % busy    0     0     0     0                       43102 numvnodes
                                                     35659 freevnodes
                                                     ^^^^^
 
 Poul-Henning and Matthew, I'd love to hear your conclusions on this so that I
 can either close this PR with a ``fixed in CURRENT/4.0'' notice or get you guys
 to wonder about the results I pasted above. =)
 
 -- 
 Jeroen Ruigrok vd W/Asmodai         asmodai@[wxs.nl|bart.nl|freebsd.org]
 Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
 The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
 Cogito, ergo sum...
 
Responsible-Changed-From-To: freebsd-bugs->dillon 
Responsible-Changed-By: dillon 
Responsible-Changed-When: Sat Feb 5 10:22:59 PST 2000 
Responsible-Changed-Why:  
Will investigate further after the 4.0 release 

From: Matthew Dillon <dillon@apollo.backplane.com>
To: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>
Cc: FreeBSD Gnats <freebsd-gnats-submit@FreeBSD.ORG>,
	jgreco@ns.sol.net, phk@FreeBSD.ORG
Subject: Re: kern/1533: Machine can be panicked by a userland program.
Date: Sat, 5 Feb 2000 10:23:42 -0800 (PST)

     Hmm.  I don't think we can close this until we do a little more research.
     The 3.x box is said to hang or crash/reboot, but what we really need 
     to know is what it is hanging or crash/rebooting on.  Since you aren't
     touching the memory being mmap()'d the problem is almost certainly that
     the 3.x box is running out KVM trying to allocate vm_map_entry structures.
     4.x scales better then 3.x but can still theoretically have the same
     problem.
 
     The likely solution to this sort of thing would be to impose a limit on
     the number of user mappings any given process is allowed to make.  
     Something on the order of 1000 would be reasonable.  It would be a good
     resource limit to add.
 
     I'll assign the bug report to myself so I don't forget about it.
 
 						-Matt
 
 

From: Joe Greco <jgreco@ns.sol.net>
To: dillon@apollo.backplane.com (Matthew Dillon)
Cc: asmodai@wxs.nl, freebsd-gnats-submit@FreeBSD.ORG,
	jgreco@ns.sol.net, phk@FreeBSD.ORG
Subject: Re: kern/1533: Machine can be panicked by a userland program.
Date: Sat, 5 Feb 2000 13:00:37 -0600 (CST)

 >     Hmm.  I don't think we can close this until we do a little more research.
 >     The 3.x box is said to hang or crash/reboot, but what we really need 
 >     to know is what it is hanging or crash/rebooting on.  Since you aren't
 >     touching the memory being mmap()'d the problem is almost certainly that
 >     the 3.x box is running out KVM trying to allocate vm_map_entry structures.
 >     4.x scales better then 3.x but can still theoretically have the same
 >     problem.
 
 This roughly matches the description of the problem that someone else who
 had looked at it provided.
 
 >     The likely solution to this sort of thing would be to impose a limit on
 >     the number of user mappings any given process is allowed to make.  
 >     Something on the order of 1000 would be reasonable.  It would be a good
 >     resource limit to add.
 
 While this is certainly a reasonable suggestion to prevent DoS attacks and
 the like, there are environments where it'd be preferable to simply have
 the system report something like ENOMEM rather than have the machine panic.
 I originally ran into this while doing some news things that mmap()'ed
 large numbers of files, and I don't think that what I was trying to do
 was unreasonable.  I do not see why a KVM failure must necessarily panic
 the system...?
 
 >     I'll assign the bug report to myself so I don't forget about it.
 
 Tx,
 
 ... Joe
 
 -------------------------------------------------------------------------------
 Joe Greco - Systems Administrator			      jgreco@ns.sol.net
 Solaria Public Access UNIX - Milwaukee, WI			   414/342-4847
 

From: Matthew Dillon <dillon@apollo.backplane.com>
To: Joe Greco <jgreco@ns.sol.net>
Cc: asmodai@wxs.nl, freebsd-gnats-submit@FreeBSD.ORG,
	jgreco@ns.sol.net, phk@FreeBSD.ORG
Subject: Re: kern/1533: Machine can be panicked by a userland program.
Date: Sat, 5 Feb 2000 11:04:09 -0800 (PST)

     We would need the resource limit in order to be able to return ENOMEM
     when the limit is reached.  If we keep allocating map_entry structures 
     until we run out of KVM, then the machine *MUST* panic because the
     structures are not disposable (unlike pagetables which can simply be
     thrown away).  The trick is not to run the system out of KVM.
 
 						-Matt
 
 

From: Joe Greco <jgreco@ns.sol.net>
To: dillon@apollo.backplane.com (Matthew Dillon)
Cc: jgreco@ns.sol.net, asmodai@wxs.nl,
	freebsd-gnats-submit@FreeBSD.ORG, phk@FreeBSD.ORG
Subject: Re: kern/1533: Machine can be panicked by a userland program.
Date: Sat, 5 Feb 2000 13:08:45 -0600 (CST)

 >     We would need the resource limit in order to be able to return ENOMEM
 >     when the limit is reached.  If we keep allocating map_entry structures 
 >     until we run out of KVM, then the machine *MUST* panic because the
 >     structures are not disposable (unlike pagetables which can simply be
 >     thrown away).  The trick is not to run the system out of KVM.
 
 Then I hope what you are proposing is a system-wide limit?  It sounded like
 a per-user or per-process limit to me, from what I read.
 
 Either way, thanks for looking at it.
 
 ... Joe
 
 -------------------------------------------------------------------------------
 Joe Greco - Systems Administrator			      jgreco@ns.sol.net
 Solaria Public Access UNIX - Milwaukee, WI			   414/342-4847
 
State-Changed-From-To: feedback->closed 
State-Changed-By: dillon 
State-Changed-When: Tue Mar 13 23:33:00 PST 2001 
State-Changed-Why:  

A per-process sysctl limit was added to avoid this problem.  The sysctl 
is vm.max_proc_mmap, I believe. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=1533 
>Unformatted:
