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.
if it doesn't there's a problem in the kernel, because a program
with no exec commands run will have no address space except the stack,
and i don't think it's valid to have a "run from stack only" exec type,
so panic. if need for that case comes up later, it can be changed...
<polk@bsdi.com>. His notes are as follows:
------------------------------------------------------------------------------
July 22, 1993
- Changed name of entire package from PCFS to MSDOSFS
- Fixed bugs:
root directory size in clusters instead of bytes
growing directory didn't update in-core size
link, symlink, mknod didn't free locked parent (deadlock)
lookup returned real error on create and rename instead of EJUSTRETURN
rename changed `.' entry in child instead of name entry in parent
rename removed `.' entry in child instead of removing entry in
parent when moving a directory from one dir to another
createde() left new node locked when write of parent failed (deadlock)
removede() decremented refcount even on error (rmdir's which failed
due to write errors left in-core cache entries inconsistent)
changed validation for filesystem to not check for the boot signature
since some disks (e.g., mtools) aren't bootable
directories are always show current time as modify time
(needed for NFS export since DOS never updates dir mod times --
ctime is true create time).
- Added support for cookies changes to the readdir() vnode
interface (#ifdef __bsdi__)
- Punted on the whole problem of inode generation numbers. This means
that there's a chance of using a stale file handle to access a new
file, but it doesn't appear to be the common case, and I don't see
how to generate reasonable generation numbers without changing something
on the disk (which is the way the SVR4 filesystem survival kit guys
did it). I don't think it would be very safe to change the on-disk
format.
Jeff Polk (polk@BSDI.COM)
------------------------------------------------------------------------------
cgd