On Fri, 22 Jan 2016, Marcelo Araujo wrote:
2016-01-22 15:57 GMT+08:00 Bruce Evans <b...@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
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
