NetBSD Problem Report #14721

Received: (qmail 2898 invoked from network); 25 Nov 2001 19:19:36 -0000
Message-Id: <20011125191936.92A491110F@www.netbsd.org>
Date: Sun, 25 Nov 2001 11:19:36 -0800 (PST)
From: manu@netbsd.org
Sender: nobody@netbsd.org
Reply-To: manu@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: It's possible to panic the system by opening a large number of files
X-Send-Pr-Version: www-1.0

>Number:         14721
>Category:       kern
>Synopsis:       It's possible to panic the system by opening a large number of files
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    jdolecek
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 25 19:20:00 +0000 2001
>Closed-Date:    Sat Jun 16 10:36:54 +0000 2018
>Last-Modified:  Sat Jun 16 10:36:54 +0000 2018
>Originator:     Emmanuel Dreyfus
>Release:        NetBSD-current
>Organization:
The NetBSD Project
>Environment:
NetBSD plume 1.5Y NetBSD 1.5Y (IRIX) #13: Sun Nov 25 15:20:49 CET 2001     manu@plume:/cvs/src/sys/arch/sgimips/compile/IRIX sgimips
>Description:
It seems it's possible to set kern.maxfiles to an arbitrary value.
Provided that the process limit on open file descriptor is set high
enough using ulimit, it's then possible to panic the kernel by opening 
a large number of files.
>How-To-Repeat:
#sysctl -w kern.maxfiles=900000000
kern.maxfiles: 1772 -> 900000000
#ulimit -n 900000000               
#cat > fdcount.c
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>

int 
main (argc, argv)
        int argc;
        char **argv;
{
        int i, fd, count;

        fd = open("/dev/null", O_RDONLY, 0);
        for (count = 1; open("/dev/null", O_RDONLY, 0) != -1; count++);
        for (i = fd; i < count; close(i++));
        printf("I opened %d descriptors\n", count);

        return 0;
}
#cc -o fdcount fdcount.c
#./fdcount
panic: malloc: out of space in kmem_map
Stopped in pid 222 (fdcount) at 0x880f84c4:     jr      ra
                bdslot: nop
>Fix:
I'm not sure about where the bug is. As I understand, kern.maxfiles is
just a limit for allocation of space for file descriptors. The space is
actually allocated when we want ot use it. 

It seems that the code that allocates memory for a new file descriptor
is not able to report ENOMEM to the calling process, it panics instead.
I think this is a bug.

Beyond this, we should at least document somewhere that setting a 
kern.* or ulimit maximum does not actually garantee that the 
resource will be available when we will request it. Of course it would 
be better to ensure it but I'm not sure it could be done without eating 
a lot of kernel memory for nothing. Is there anything in the X/Open standards about the behaviour of ulimit? 
>Release-Note:
>Audit-Trail:

From: Jaromir Dolecek <jdolecek@netbsd.org>
To: manu@netbsd.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/14721: It's possible to crash the system by opening a large
 number of files
Date: Sun, 25 Nov 2001 20:35:12 +0100 (CET)

 manu@netbsd.org wrote:
 > panic: malloc: out of space in kmem_map
 > Stopped in pid 222 (fdcount) at 0x880f84c4:     jr      ra
 >                 bdslot: nop

 The stack backtrace would be useful here.
 Does this exist on other archs?

 Jaromir
 -- 
 Jaromir Dolecek <jdolecek@NetBSD.org> http://www.NetBSD.org/Ports/i386/ps2.html
 -=  Those who would give up liberty for a little temporary safety deserve  =-
 -=  neither liberty nor safety, and will lose both.  -- Benjamin Franklin  =-
Responsible-Changed-From-To: kern-bug-people->jdolecek 
Responsible-Changed-By: jdolecek 
Responsible-Changed-When: Sun Nov 25 11:34:04 PST 2001 
Responsible-Changed-Why:  
I'm currently chasing different descriptor-related panic, might 
as well look at this one too. 

From: Jaromir Dolecek <jdolecek@netbsd.org>
To: David Laight <David.Laight@btinternet.com>
Cc: manu@netbsd.org, tech-kern@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: kern/14721: It's possible to crash the system by opening a large
 number of files
Date: Sun, 25 Nov 2001 21:22:19 +0100 (CET)

 David Laight wrote:
 > > Beyond this, we should at least document somewhere that setting a 
 > > kern.* or ulimit maximum does not actually garantee that the 
 > > resource will be available when we will request it.
 > 
 > Nothing (I recall) in the X/Open spec stops open() (or t_open() or socket()
 > - which I've discussed at XNET meetings) from failing due to 'transient
 > lack of resource'.

 Right, kern.maxfiles is only _limit_ of maximum open files, it
 does not guarantee you'd be able to open that many files. If you
 need that many, you'd need to get appropriate hw resources
 for that.

 Obviously, it's broken when kernel panics when the hw resources
 are depleted, it should fail in normal way (i.e., just returning
 error to the application).

 Jaromir
 -- 
 Jaromir Dolecek <jdolecek@NetBSD.org> http://www.NetBSD.org/Ports/i386/ps2.html
 -=  Those who would give up liberty for a little temporary safety deserve  =-
 -=  neither liberty nor safety, and will lose both.  -- Benjamin Franklin  =-

From: Jaromir Dolecek <jaromir.dolecek@artisys.cz>
To: gnats-bugs@netbsd.org, manu@netbsd.org
Cc:  
Subject: Re: kern/14721: It's possible to crash the system by opening a large
 number of files
Date: Mon, 26 Nov 2001 11:48:37 +0100 (CET)

 Hi,
 this is most likely due to the array holding file strcure
 pointers becoming too large. Quick fix would be to change
 M_WAITOK to M_NOWAIT in malloc() call in kern_desscrip.c:fdexpand(),
 check if malloc() returns NULL and handle this appropriately.

 Real fix is to add some way to indicate to vm subsystem we
 are willing to sleep, but are prepared to handle situation
 when the resources cannot be ever allocated. Will think
 about this more and discuss on tech-kern.

 Jaromir
 -- 
 Jaromir Dolecek <jaromir.dolecek@artisys.cz>
 ARTISYS, s.r.o., Stursova 71, 61600 Brno, Czech Republic
 phone: +420-5-41224836 / fax: +420-5-41224870 / http://www.artisys.cz
State-Changed-From-To: open->analyzed
State-Changed-By: jdolecek@NetBSD.org
State-Changed-When: Mon, 05 Jul 2010 20:24:19 +0000
State-Changed-Why:
It seems 5.0.1 doesn't panic, but at some point stops chewing 100% CPU. Need
to investigate this further.


Responsible-Changed-From-To: jdolecek->kern-bug-people
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Sun, 15 Apr 2012 21:40:05 +0000
Responsible-Changed-Why:
Back to role account, jdolecek left


Responsible-Changed-From-To: kern-bug-people->jdolecek
Responsible-Changed-By: jdolecek@NetBSD.org
Responsible-Changed-When: Wed, 11 Jan 2017 08:34:18 +0000
Responsible-Changed-Why:
I'm back.


State-Changed-From-To: analyzed->closed
State-Changed-By: jdolecek@NetBSD.org
State-Changed-When: Sat, 16 Jun 2018 10:36:54 +0000
State-Changed-Why:
Panic is gone, and otherwise it's responsibility of the admin to
set the limits according to what system can handle.


>Unformatted:

Home	PR Database Search