Date: Tue, 17 Oct 1995 15:35:22 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bakul@netcom.com (Bakul Shah) Cc: terry@lambert.org, bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? Message-ID: <199510172235.PAA28761@phaeton.artisoft.com> In-Reply-To: <199510171851.LAA28198@netcom23.netcom.com> from "Bakul Shah" at Oct 17, 95 11:51:24 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I don't see where this massive amount of runtime work is really worth it.
>
> It is not massive amount of runtime work. Changes are
> fairly straight forward. The runtime cost is small.
>
> It is worth it to me. But a more general argument is that
> without this fix file descriptors > FD_SETSIZE are second
> class citizens. You _are_ a fan of consistency, are you?:-)
Basically, all of the user space code that uses the standard-since-4.2
sys/types.h definitions would need to be rewritten. This is what I
meant.
> > /usr/unclude/sys/types.h has the forllowing in it:
>
> > #ifndef FD_SETSIZE
> > #define FD_SETSIZE 256
> > #endif
>
> This is well and good for *user* programs. Most programs don't
> want to bother with changing FD_SETSIZE and kernel changes
> I am proposing are transparent to such programs.
???
How do I make a program which doesn't guard using FD_SETSIZE the max fd
it tries to select upon suddenly have a larger statically or stack
declared bitvector array?
I can't.
Programs that "don't bother" will get the FD_SETSIZE limit or get an
error from the kernel, or more likely, corrupt whatever data lives
right after where the fd_set lives and eventually mysteriously fail.
Checking the limit isn't optional. Reacting to a discrepancy between
the user and kernel limits (ie: handling error returns from select) is
also not optional.
Setting the limit: that's optionalm both in the kernel and in user space.
> > meaning you can option it higher in the kernel and you can #define it
> > higher before including <sys/types.h>.
>
> This is not a good option for commercial software.
> Customers generally don't like to rebuild the kernel for
> such things. So I am forced to use the more complex
> solution.
I don't see how you prevent the kernel from twiddling user bits that
follow the fd_set declaration area in the processes address space
(or getting a SEGV if it's the last item in the data segment) as a
result of shoving down a number that wasn't guarded based on the
user's FD_SETSIZE.
This seems to be a recipe for bizarre and undetectable data corruption.
> It is difficult enough to convince companies to support
> {Net,Free}BSD -- unfortunately a lot more difficult than
> Linux (which is wildly more popular inspite of its growing
> pains) -- and this sort of scaling problems makes it harder
> -- especially when Solaris, IRIX etc. already do them right.
If we change the macro names, that means source changes for the
people doing the porting, and that won't go over well.
The problem occurs in large service sites.
And the problem is related to the kernel not knowing how big the
user FD_SETSIZE is at select call time.
I don't see that going away without an interface change.
> Fair enough. So just do
> #define __inline__ /*inline*/
> :-)
#define __inline__ static
?
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510172235.PAA28761>