rick@snowhite.cis.uoguelph.ca:
1. Clear B_NEEDCOMMIT in nfs_write to make sure that dirty data is
correctly send to the server. If a buffer was dirtied when it was in
the B_DELWRI+B_NEEDCOMMIT state, the state of the buffer was left
unchanged and when the buffer was later cleaned, just a commit rpc was
made to the server to complete the previous write. Clearing
B_NEEDCOMMIT ensures that another write is made to the server.
2. If a server returned a server (for whatever reason) returned an
answer to a write RPC that implied that fewer bytes than requested
were written, bad things would happen.
3. The setattr operation passed on the atime in stead of the mtime to
the server. The fix is trivial.
4. XIDs always started at 0, but this caused some servers (older DEC
OSF/1 3.0 so I've been told) who had very long-lasting XID caches to
get confused if, after a reboot of a BSD client, RPCs came in with a
XID that had in the past been used before from that client. Patch is
to use the current time in seconds as a starting point for XIDs. The
patch below is not perfect, because it requires the root fs to be
mounted first. This is because of the check BSD systems do, comparing
FS time to system time.
Reviewed by: Bruce Evans, Terry Lambert.
Obtained from: frank@fwi.uva.nl (Frank van der Linden) via rick@snowhite.cis.uoguelph.ca
I usually test, so... :-( Guess we'll have to slide the tag forward on
these two files - Peter, could you do the honors? I've been up for the last
30 hours or so and I just *know* that any attempt on my part to do this would
probably end up deleting the entire repository somehow. :-)
directly in order to obtain binding information, check that the local
ypbind is using a reserved port and return YPERR_YPBIND if it isn't.
We should not trust any ypbind running on a port >= IPPORT_RESERVED;
it may have been started by a malicious user hoping to trick us into
talking to a bogus ypserv.
Note that we do not check the ypserv port returned to us from ypbind.
It is assumed that ypbind has already done a reserved port test (or not,
depending on whether or not it was started with -s); if we trust the
authenticity of the local ypbind, we should also trust its judgement.
Obtained from: OpenBSD
(author's explaination):
Bit 15 is the flag to request a transmit complete interrupt. The
driver was apparently written to minimize interrupts, and if not for a
3-COM design quirk, everything would be just ducky.
Prior to loading the outbound packet into the FIFO, the driver checks
to see if there's enough space to contain the packet. If not, the
driver requests a transmit-available interrupt when there is
sufficient room. Unfortunately, the card is continuing to process the
prior FIFO, and by the time the driver sets the threshold for a
transmit available interrupt, the space is already available. When
this occurs, the 3COM card ignores the interrupt request, and the
driver is hung waiting for an interrupt that will never occur.
There's probably a more elegant solution, but requesting the transmit
complete interrupt was the easiest to implement. An alternative fix
might be to check free FIFO space again, after requesting the transmit
available interrupt, but I haven't bothered pursuing this. Since the
patch, my 3C590 (PCI, same FIFO interface as 3C509) has been rock
solid.
Submitted by: mevans@candle.com (Mike Evans)
pulled up already. This bug can cause the first packet from a source
to a group to be corrupted when it is delivered to a process listening
on the mrouter.
2.1.5-RELEASE). This will obviously be set "for real" closer to the time.
(some ports use this to differentiate the two branches /dev/kmem kernel
architectures. This exact same procedure happened in November last year
for the 2.1 RELEASE as well.)
Fixed initialization of pipe_pgid - don't default to pid 0 (swapper) for
SIGIO.
Added comments about other implicit initializations, mostly for struct
stat.
Fixed initialization of st_mode. S_IFSOCK was for when pipes were sockets.
It is probably safe to fix the bogus S_ISFIFO() now that pipes can be
distinguished from sockets in all cases.
Don't return ENOSYS for inappropriate ioctls.
for big positive adjustments. The existence of big adjustments may
be a bug (it's not documented...) but there was no good reason for
the asymmetric behaviour.
Reviewed by: wollman
