svn commit: r294543 - head/usr.sbin/ypldap

[Bruce Evans]

On Fri, 22 Jan 2016, Marcelo Araujo wrote:

> 2016-01-22 15:57 GMT+08:00 Bruce Evans <brde at optusnet.com.au>:
>> ...
>> Unfortunately, getdtablesize() is still needed for arrays as used in yp*,
>> and for anything using select().  If getdtablesize() is large then the
>> arrays should be sparse or large fd's should not be actually used.
>> closefrom() should probably be used early to kill unknown fd's to make
>> space for private fd's.  After that, getdtablesize() becomes almost
>> useless.  You just allocate a table large enough for the fd's that
>> you allocate, and don't allocate fd's sparsely.
>> ...
>
> I noticed that getdtablesize(2) specifically for ypldap(8) case is a bit
> slower than FD_SETSIZE, mostly because of the size of max_fd.

freefall actually takes only 0.11 seconds to close 706977 mostly-non-open
fd's.  But if you watch this using ktrace (with ktrace.out on nfs) it takes
2.79 seconds for 1000 fd's or 33 minutes.  ktrace on nfs is unusably slow.

> However, as ypldap(8) was imported from OpenBSD seemed good to keep it as
> much as synced with OpenBSD implementation. Although I'm not sure if
> FreeBSD and OpenBSD shares the same getdtablesize(2) implementation.

How did it diverge in the first place?

getdtablesize(2)'s implementation can't be much different, but its value
should be.  Allowing 706977 fd's for a single thread should be considered
a security hole (just a denial of service one).

> Not an excuse for sure, but I agree with you!!!

Bruce