Commit Graph

14 Commits

Author SHA1 Message Date
Peter Wemm
7f3dea244c $Id$ -> $FreeBSD$ 1999-08-28 00:22:10 +00:00
Bill Paul
4c45fb08aa Correct a bug in the 'allow arbitrary number of socket descriptors' changes
made to the RPC code some months ago. The value of __svc_fdsetsize is being
calculated incorrectly.

Logically, one would assume that __svc_fdsetsize is being used as a
substitute for FD_SETSIZE, with the difference being that __svc_fdsetsize
can be expanded on the fly to accomodate more descriptors if need be.
There are two problems: first, __svc_fdsetsize is not initialized to 0.
Second, __svc_fdsetsize is being calculated in svc.c:xprt_registere() as:

                __svc_fdsetsize = howmany(sock+1, NFDBITS);

This is wrong. If we are adding a socket with index value 4 to the
descriptor set, then __svc_fdsetsize will be 1 (since fds_bits is
an unsigned long, it can support any descriptor from 0 to 31, so we
only need one of them). In order for this to make sense with the
rest of the code though, it should be:

                __svc_fdsetsize = howmany(sock+1, NFDBITS) * NFDBITS;

Now if sock == 4, __svc_fdsetsize will be 32.

This bug causes 2 errors to occur. First, in xprt_register(), it
causes the __svc_fdset descriptor array to be freed and reallocated
unnecessarily. The code checks if it needs to expand the array using
the test: if (sock + 1 > __svc_fdsetsize). The very first time through,
__svc_fdsetsize is 0, which is fine: an array has to be allocated the
first time out. However __svc_fdsetsize is incorrectly set to 1, so
on the second time through, the test (sock + 1 > __svc_fdsetsize)
will still succeed, and the __svc_fdset array will be destroyed and
reallocated for no reason.

Second, the code in svc_run.c:svc_run() can become hopelessly confused.
The svc_run() routine malloc()s its own fd_set array using the value
of __svc_fdsetsize to decide how much memory to allocate. Once the
xprt_register() function expands the __svc_fdset array the first time,
the value for __svc_fdsetsize becomes 2, which is too small: the resulting
calculation causes the code to allocate an array that's only 32 bits wide
when it actually needs 64 bits. It also uses the valuse of __svc_fdsetsize
when copying the contents of the __svc_fdset array into the new array.
The end result is that all but the first 32 file descriptors get lost.

Note: from what I can tell, this bug originated in OpenBSD and was
brought over to us when the code was merged. The bug is still there
in the OpenBSD source.

Total nervous breakdown averted by: Electric Fence 2.0.5
1997-10-14 21:50:17 +00:00
Bill Paul
ad133ed648 Resolve conflicts.
This concludes tonight's entertainment. Once I'm sure I haven't destroyed
the world with all these changes, I'll import the utilities. Everything
should continue to work as before. If it doesn't let me know.

Special thanks to Mark Murray for running a test 'make world' for me to
shake out the bugs, which, hopefully, I have fixed.

(And there was much rejoicing.)
1997-05-28 05:05:31 +00:00
Peter Wemm
7e546392b5 Revert $FreeBSD$ to $Id$ 1997-02-22 15:12:41 +00:00
Jordan K. Hubbard
1130b656e5 Make the long-awaited change from $Id$ to $FreeBSD$
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.

Boy, I'm glad we're not using sup anymore.  This update would have been
insane otherwise.
1997-01-14 07:20:47 +00:00
Jordan K. Hubbard
799dbaaffc Eliminate unnecessary warning introduced by a missing forward declaration. 1997-01-01 10:06:37 +00:00
Peter Wemm
a856779ff8 prototype of shared function now in include file 1996-12-31 09:16:12 +00:00
Peter Wemm
ae1e6afd31 - major overhaul to make this deal with unlimited fd's.
- kill non-FD_SETSIZE code

Obtained from: a diff of FreeBSD vs. OpenBSD/NetBSD rpc code.

Note, there was a nasty bug with our old code here.  It would trash the
stack if a fd > 31 was passed in.  It was using a "long" as though it
was an "fd_set", ie: it was assuming that a long was 256 bits wide. :-(
This has been lurking here for a while, since the FD_SETSIZE #ifdef's
were first implemented.
1996-12-30 15:07:33 +00:00
Peter Wemm
54edc0bbbf clear various struct sockaddr_in's on stack, set sin_len.
(Noticed when comparing to OpenBSD source)
1996-08-12 14:00:26 +00:00
James Raynard
b2843ce288 Code cleanup:
Fixed a couple of nitpick warnings, plus one that slipped through the
net earlier.

This directory now compiles without any warnings with -Wall! (Until
the next gcc upgrade...)
1996-06-11 17:22:51 +00:00
James Raynard
7d6a21b4d7 Code cleanup (part two):
1. Added missing function prototypes.
2. Added missing function return types.
3. Added missing function argument types.
4. Added missing headers for system function prototypes.
5. Corrected casts in select() args.
6. Got rid of more "extern int errno" rubbish.
7. Added extra parentheses around assignment used as truth value.
8. Fixed bug in clnt_{tcp, udp}create() where pointers could be free'd
    even if they hadn't been successfully malloc()'d.
1996-06-10 00:49:19 +00:00
Poul-Henning Kamp
4c3af266f6 Well, cvs commit core'ed on me, I belive I have got all the locks out,
but a commit mail got lost, it's the same as for this commit:

 lib/libc/gen  confstr.c crypt.c disklabel.c fstab.c getcap.c
          getgrent.c  getgrouplist.c getpass.c getpwent.c
          initgroups.c nlist.c  psignal.c pwcache.c setmode.c
          sleep.c sysconf.c sysctl.c  syslog.c usleep.c
 lib/libc/locale  none.c read_runemagi.c setlocale.c
 lib/libc/net  gethostbydns.c getnetbydns.c getnetbynis.c
 lib/libc/nls  msgcat.c
 lib/libc/quad  Makefile.inc
 lib/libc/regex  engine.c regcomp.c regerror.c

	Minor cleanup, mostly unused vars and missing #includes.
	Limit the number of quad functions we pull in for 'i386'.
	I still belive the quad stuff should go back into gcc.
	Add compile-time warnings about crypt functions.
1995-10-22 14:51:39 +00:00
Rodney W. Grimes
6c06b4e2aa Remove trailing whitespace. 1995-05-30 05:51:47 +00:00
Garrett Wollman
990647991e Moving Sun RPC code into libc, part 1. Based on work done by a number of
people, including J.T. Conklin, Theo de Raadt, Paul Richards, and probably
someone else who's going to flame me as soon as they see this message.
1994-08-07 18:36:12 +00:00