Date: Wed, 10 Dec 2008 17:00:04 +0200 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: MAXFILES in subr_param.c Message-ID: <87fxkwdqiz.fsf@kobe.laptop> In-Reply-To: <ghjt9l$hg3$1@ger.gmane.org> (Ivan Voras's message of "Mon, 08 Dec 2008 20:41:32 %2B0100") References: <ghjt9l$hg3$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 08 Dec 2008 20:41:32 +0100, Ivan Voras <ivoras@freebsd.org> wrote:
> Hi,
>
> I'm looking at kern/subr_param.c:
>
> 72 #ifndef MAXFILES
> 73 #define MAXFILES (maxproc * 2)
> 74 #endif
>
> Shouldn't this be at least maxproc*3, for stdin,out,err for every proc?
>
> Also, it looks like MAXFILES is used only once, and in a bit funny way:
>
> 238 maxfiles = MAXFILES;
> 239 TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles);
> 240 maxprocperuid = (maxproc * 9) / 10;
> 241 maxfilesperproc = (maxfiles * 9) / 10;
This is an attempt to limit a rogue process from grabbing the full
maxfiles or maxproc value by opening too many files. There will still
be (maxfiles / 10) file descriptors available and (maxproc / 10) process
table entries, so that you can for example try to log into the system
as root and try to fix things.
You can still cause all sorts of trouble by *forking* and then going off
into a file descriptor allocation spree, but as I said this is an
_attempt_ at keeping things in a relatively sane state in the _default_
state. You can still use the loader to set the actual values of the
`kern.maxprocperuid' and `kern.maxfilesperproc' tunables to something
that is more robust for your particular application.
The defaults are just a `best effort' guess to keep things working in
the most common case. Nothing funny about them :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87fxkwdqiz.fsf>