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%.
(1) text calculation incorrect (would 'overbill')
(2) data calculation incorrect (would 'overbill')
(3) the maxrss calculation uses stuff which isn't present
on the sparc.
if 3/4 tests are questionable and/or broken, well...
SUMMARY:
"panic: vrele: null vp", the problem seems to be that two renames are
moving the same source, and the second one can't do it.
ALSO:
in sync, check that rootfs is non-null before using it.
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.
structural changes should happen, as it now does the right thing
w.r.t. buffer resizing and having lots of buffers vs. relatively
little buffer space. Ports can now "do the standard thing", re:
nbuf and bufpages, which is make nbuf = bufpages by default.
startup in machdep.c... buffers are now *never* allocated after boot.
currently, the limitation that says bufpages must cover nbuf*MAXBSIZE
still exists, but this is one step closer to removing that limitation.
func(short) and the fact the the kernel uses full ints. This caused
problems on the pc532 port. These fixes take the good 16 bits passed
by the user program and converts them into the correct form for the
kernel.
how much of the file to pass in the exec package, but i think the
solution to that will be to pass e.g. a disk block's worth, or whatever;
if exec handlers really need more, they've got the damned vnode.
