targets, have "distribution" always install original (as from the release
media) files, whether SENDMAIL_MC is set or not. Do error handling the
make(1) way.
Reviewed by: gshapiro
Approved by: gshapiro
rid's and to deallocate resources if a failure occurs during attach. This
patch also fixes the driver to return failure if bus_alloc_resource() for
the IRQ fails rather than panic'ing on the next line by passing a NULL
resource to bus_setup_intr(). The other attachments already do all this.
Submitted by: Jun Su <csujun@263.net>
In case no real/physical IEEE 802 address is available, both the expired
"draft-leach-uuids-guids-01" (section "4. Node IDs when no IEEE 802
network card is available") and RFC 2518 (section "6.4.1 Node Field
Generation Without the IEEE 802 Address") recommend (quoted from RFC
2518):
"The ideal solution is to obtain a 47 bit cryptographic quality random
number, and use it as the low 47 bits of the node ID, with the _most_
significant bit of the first octet of the node ID set to 1. This bit
is the unicast/multicast bit, which will never be set in IEEE 802
addresses obtained from network cards; hence, there can never be a
conflict between UUIDs generated by machines with and without network
cards."
Unfortunately, this incorrectly explains how to implement this and
the FreeBSD UUID generator code inherited this generation bug from
the broken reference code in the standards draft. They should instead
specify the "_least_ significant bit of the first octet of the node ID"
as the multicast bit in a memory and hexadecimal string representation
of a 48-bit IEEE 802 MAC address.
This standards bug arised from a false interpretation, as the multicast
bit is actually the _most_ significant bit in IEEE 802.3 (Ethernet)
_transmission order_ of an IEEE 802 MAC address. The standards authors
forgot that the bitwise order of an _octet_ from a MAC address _memory_
and hexadecimal string representation is still always from left (MSB,
bit 7) to right (LSB, bit 0).
Fortunately, this UUID generation bug could have occurred on systems
without any Ethernet NICs only.
return for getopt() and comparing to -1, ditto with fgetc() and EOF,
and using the kg_nice value from <sys/user.h>
Submitted by: Stefan Farfeleder <stefan@fafoe.narf.at>
Reviewed by: obrien, bde (a while back)
Tested lightly on: ppc, i386, make universe
no-op on {i386/alpha/ia64/sparc64} where chars are signed by
default. Should help ARM and S390 which also suffer from this.
Tested on: ppc, i386, objdump disasm before/after diffs
Reviewed by: obrien, bde (a while back)
from log[10](largest file size), but when outputting in human-friendly
format the width is always at most 4. (eg. "123K", " 12K", "1.2K".)
PR: bin/59320
Approved by: rwatson (mentor)
1. If fgets fails, don't go into an infinite cpu-intensive loop. Instead,
check to see if the terminal still exists, and sleep(1) otherwise.
2. When we check to see if the terminal still exists, make sure we're not
mislead by EINTR. This could have been a security issue, but fortunately
the current implementation of tcgetattr doesn't EINTR.
PR: bin/60758
Approved by: rwatson (mentor)
network interface cards smart (or twisted?) enough to be able
to calculate a TCP/UDP checksum for a packet fragmented by the
host CPU. Therefore the paragraph on the case has been revised.
use a bounce buffer for the actual transfer to avoid crossing a 64k
boundary. To do this, we malloc a buffer twice as big as we need and then
find an aligned block within that buffer to do the transfer. The check
to see which part of the block we use used the wrong variable for part of
the condition meaning that in certain edge cases we would ask the BIOS to
cross a 64k boundary. The BIOS request would then fail resulting in file
transfers that just magically fail in the middle without any apparent
reason. Specifically, my tests for the splitfs boot floppies managed to
trigger this edge case.
MFC after: 1 week
X-MFC-info: along with fixes to libstand filesystems
- bzipfs and gzipfs now properly return errno values directly from their
read routines rather than returning -1.
- missing errno values on error returns for the seek routines on almost
all filesystems were added.
- fstat() now returns -1 if an error occurs rather than ignoring it.
- nfs's readdir() routine now reports valid errno values if an error or
EOF occurs rather than EPERM (It was just returning 0 for success and
1 for failure).
- nullfs used the wrong semantics for every function besides close() and
seek(). Getting it right for close() appears to be an accident at that.
- read() for buffered files no longer returns 0 (EOF) if an error occurs,
but returns -1 instead.
Presumably, at some point, you had to include jail.h if you included
proc.h, but that is no longer required.
Result of: self injury involving adding something to struct prison
life easier" patch: I doubt this will affect anyone else, but the FreeBSD
Update build code was getting very confused by this.
Approved by: rwatson (mentor)
PR: bin/61087
From the NEWS file of cvs 1.11.11:
* pserver can no longer be configured to run as root via the
$CVSROOT/CVSROOT/passwd file, so if your passwd file is
compromised, it no longer leads directly to a root hack. Attempts
to root will also be logged via the syslog.
* Malformed module requests could cause the CVS server to attempt
to create directories and possibly files at the root of the
filesystem holding the CVS repository. Filesystem permissions
usually prevent the creation of these misplaced directories, but
nevertheless, the CVS server now rejects the malformed requests.
Obtained from: ccvs.cvshome.org
* Remove mention of '>', 'A', and 'S' states
* Mention 'W' state.
* List 'J' state in the correct location.
* Sync with flags in sys/proc.h
Approved by: rwatson (mentor)
MFC after: 7 days
