Date: Wed, 7 Oct 1998 00:30:45 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mishania@demos.net (Mikhail A. Sokolov) Cc: tlambert@primenet.com, dg@root.com, enkhyl@hayseed.net, mishania@demos.net, current@FreeBSD.ORG Subject: Re: -current panics.. Message-ID: <199810070030.RAA13270@usr04.primenet.com> In-Reply-To: <19981007001308.11085@demos.su> from "Mikhail A. Sokolov" at Oct 7, 98 00:13:08 am
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... dynamic resource working set sizing ... ] > Talking about being AIX-ish - the precedent is there - FDSETSIZE, isn' it? I'll assume you mean either: sysconf( _SC_OPEN_MAX ) or getdtablesize(); and not FD_SETSIZE? No. The existance of the interfaces to get the number of descriptors available to a process is a kludge. The reason it exists is for badly written programs that try to open the largest fd possible in order to avoid the stdin/script confusion... in general, scripting languages. The biggest offender in this regard, prior to the imposition of hard limits on number of desciptors in use in FreeBSD was "bash". The "bash" programmers were to lazy to do the "tail chase" required to move the saved descriptor off the used descriptor when the used descriptor ID was referenced in a shell script (for example, when doing file I/O within a shell script). When the descriptor is referenced, it *can't* be the descriptor for the script that is currently executing. Basically, this means that shells need "hidden descriptors". Number stuffing these descriptors fails for constructs like: # call program foo, and tell it to use our already open # file descriptor 7 as stdin... foo <&7 Or worse: # call program fee; tell it which descriptor we connected # so it can atoi( av[ 1]) it and use it for I/O... fee 7 To fix this, you would have to maintain a collision map in the shell descriptor managemetn code. Much better to open up 2^32 fd's, one after the other... NOT! The typical behaviour was "bash" took forever to start up, and then effectively used up all available kernel memory in the process. Problem: bash is broken Solution: hack FreeBSD to pieces and make it hard for things like SAMBA and Apache to work like they are supposed to without having to hire a UNIX system administrator Now, with FD_SETSIZE, we only have the problem of someone passing a number larger than FD_SETSIZE as the first argument to select, and the system going off into the weeds. Basically, this is what happened in the old LDAP code, where the implementors at UMICH really didn't understand how select(2) works. The upshot? Dynamically sized resources which are directly exploitable by the user are a bad idea, iff: 1) you have a malicious user or 2) some idiot who doesn't know how to program, or knows, but is too lazy to Do The Right Thing Is using your system. For mbuf's, this is not the same thing... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810070030.RAA13270>