the process (i.e. pre-Reno behavior). The 4.4BSD behavior (introduced
in Reno) caused transient errors to stick incorrectly.
This is from PR #7640 (Havard Eidnes), cross-checked w/ FreeBSD, where
Bill Fenner committed the same fix (as described in a comment in the
Vat sources, by Van Jacobsen).
serious race condition in sosend(). Upon closer inspection, the appropriate
flags are checked within splsoftnet() for soreceive(), so no change needed
there. Also a little KNFing in sosend().
same uid or by root.
This code is from FreeBSD. (Whilst it was originally obtained from OpenBSD,
FreeBSD fixed it to work with multicast. To quote the commit message:
- Don't bother checking for conflicting sockets if we're binding to a
multicast address.
- Don't return an error if we're binding to INADDR_ANY, the conflicting
socket is bound to INADDR_ANY, and the conflicting socket has
SO_REUSEPORT set.
)
set SS_MORETOCOME as a hint to the lower layer that more data is coming
on the next iteration of the loop. Clear the flag after the PRU_SEND
call.
Suggested by Justin Walker <justin@apple.com> on the freebsd-net
mailing list.
so_linger is used as an argument to tsleep(), so was stuffed with
clockticks for the TCP linger time. However, so_linger is set directly from
l_linger if the linger time is specified, and l_linger is seconds (although
this is not currently documented anywhere). Fix this to set the TCP
linger time in seconds, and multiply so_linger by hz when tsleep() is
called to actually perform the linger.
- Disallow < 1 values for SO_SNDBUF, SO_RCVBUF, SO_SNDLOWAT, and
SO_RCVLOWAT; return EINVAL if the user attempts to set <= 0.
Inspired by PR #3770, from Havard Eidnes <he@vader.runit.sintef.no>.
- For SO_SNDLOWAT and SO_RCVLOWAT, don't let the low-water mark get
set above the high-water mark. Behavior is now consistent with
BSD/OS: If such an attempt is made, silently truncate to the high-water
value.
programs which attach their own header) can crash the machine. The problem
in this case was:
a variable "space" was set to the total data to copy,
len was used to remember how much to copy in this chunk (mbuf),
in one case, len = min(MCLBYTES - max_hdr, resid) but
size -= MCLBYTES;
instead of
size -= len;
Note that userland programs can still crash the machine by providing
bogus data in the ip->ip_len field I suspect. I haven't verified this,
but will soon be doing so and applying a fix of some sort. Probably
clamping the ip->ip_len value to the true packet size will be ok.
sosend was attempting to reserve space in an mbuf cluster for a datagram
header and because of bugs in the sosend's mbuf allocation algorithm,
sosend was calling uiomove twice as many times as was necessary. It turns
out that PREPEND does the right thing when a cluster is associated with
an mbuf header, so the datagram header allocation can be defered. This
also ends up additionally consuming one less mbuf for the TCP protocol
because TCP always allocates another header mbuf regardless if space is
available to prepend the protocol header. The net result of this fix is
that unix domain and pipe throughput is increased by a measured 10%.
SUMMARY:
Here is a patch for a kernel hang that can be provoked with a write
or send of a negative amount. The talk program is capable of exercising
this bug. This patch also includes a fix for a bug that caused data
to be delivered to TCP in smaller chunks than desired, and which caused
TCP to send a short packet when starting up. Finally, there is a bug
fix for MSG_PEEK with an oobmark pending.
* Yuval Yarom's socket recv(2) fixes, to prevent incorrect blocking and
lack thereof with recv(2) and MSG_WAITALL. Fixes a sbdrop() panic during
some MSG_WAITALL recv(2) sleeps. Access rights fix (also in
uipc_syscalls.c) too. A test program which shows these problems is
available.
thorpej