csjp [Mon, 28 Jan 2008 17:33:46 +0000 (17:33 +0000)]
Make sure that the termid type is initialized to AU_IPv4 by default.
This makes sure that process tokens credentials with un-initialized
audit contexts are handled correctly. Currently, when invariants are
enabled, this change fixes a panic by ensuring that we have a valid
termid family. Also, this fixes token generation for process tokens
making sure that userspace is always getting a valid token.
This is consistent with what Solaris does when an audit context is
un-initialized.
rwatson [Mon, 28 Jan 2008 10:20:18 +0000 (10:20 +0000)]
Properly return the error from mls_subject_privileged() in the ifnet
relabel check for MLS rather than returning 0 directly.
This problem didn't result in a vulnerability currently as the central
implementation of ifnet relabeling also checks for UNIX privilege, and
we currently don't guarantee containment for the root user in mac_mls,
but we should be using the MLS definition of privilege as well as the
UNIX definition in anticipation of supporting root containment at some
point.
MFC after: 3 days
Submitted by: Zhouyi Zhou <zhouzhouyi at gmail dot com>
Sponsored by: Google SoC 2007
das [Mon, 28 Jan 2008 01:19:07 +0000 (01:19 +0000)]
Adjust the exponent before converting the result from double to
float precision. This fixes some double rounding problems for
subnormals and simplifies things a bit.
mtm [Sun, 27 Jan 2008 10:15:36 +0000 (10:15 +0000)]
Add the -M command-line option, which will set home directory permissions.
Works both in interactive or batch mode. This is a heavily modified version
of the patch submitted in the PR.
marius [Sun, 27 Jan 2008 01:30:02 +0000 (01:30 +0000)]
- Fix a typo in a comment.
- Fix whitespace according to style(9).
- Sync the comment describing why we have to wait in nsphy_reset()
with nsphyter_reset(). It's true that the manual tells to not do a
reset within 500us of applying power but that's unlikely the cause
of problems seen here. Generally having to wait 500us after a reset
however is.
jb [Sun, 27 Jan 2008 01:19:47 +0000 (01:19 +0000)]
fts_pathlen is now a size_t rather than an int so a cast is needed.
I'm not sure why warn() and err() string formatted variables need
to be right-justified.
marius [Sun, 27 Jan 2008 01:10:41 +0000 (01:10 +0000)]
Add a driver for the National Semiconductor DP83815, DP83843 and
DP83847 PHYs. The main reason for using a specific driver for these
PHYs are reset quirks similar to the nsphy(4) driven DP83840A.
PR: 112654
Obtained from: NetBSD
MFC after: 2 weeks
Thanks to: mlaier for testing w/ DP83815
rwatson [Sat, 26 Jan 2008 22:32:23 +0000 (22:32 +0000)]
Allow DDB_CAPTURE_DEFAULTBUFSIZE and DDB_CAPTURE_MAXBUFSIZE to be
overridden at compile-time using kernel options of the same names.
Rather than doing a compile-time CTASSERT of buffer sizes being
even multiples of block sizes, just adjust them at boottime, as
the failure mode is more user-friendly.
yar [Sat, 26 Jan 2008 17:09:40 +0000 (17:09 +0000)]
Our fts(3) API, as inherited from 4.4BSD, suffers from integer
fields in FTS and FTSENT structs being too narrow. In addition,
the narrow types creep from there into fts.c. As a result, fts(3)
consumers, e.g., find(1) or rm(1), can't handle file trees an ordinary
user can create, which can have security implications.
To fix the historic implementation of fts(3), OpenBSD and NetBSD
have already changed <fts.h> in somewhat incompatible ways, so we
are free to do so, too. This change is a superset of changes from
the other BSDs with a few more improvements. It doesn't touch
fts(3) functionality; it just extends integer types used by it to
match modern reality and the C standard.
Here are its points:
o For C object sizes, use size_t unless it's 100% certain that
the object will be really small. (Note that fts(3) can construct
pathnames _much_ longer than PATH_MAX for its consumers.)
o Avoid the short types because on modern platforms using them
results in larger and slower code. Change shorts to ints as
follows:
- For variables than count simple, limited things like states,
use plain vanilla `int' as it's the type of choice in C.
- For a limited number of bit flags use `unsigned' because signed
bit-wise operations are implementation-defined, i.e., unportable,
in C.
o For things that should be at least 64 bits wide, use long long
and not int64_t, as the latter is an optional type. See
FTSENT.fts_number aka FTS.fts_bignum. Extending fts_number `to
satisfy future needs' is pointless because there is fts_pointer,
which can be used to link to arbitrary data from an FTSENT.
However, there already are fts(3) consumers that require fts_number,
or fts_bignum, have at least 64 bits in it, so we must allow for them.
o For the tree depth, use `long'. This is a trade-off between making
this field too wide and allowing for 64-bit inode numbers and/or
chain-mounted filesystems. On the one hand, `long' is almost
enough for 32-bit filesystems on a 32-bit platform (our ino_t is
uint32_t now). On the other hand, platforms with a 64-bit (or
wider) `long' will be ready for 64-bit inode numbers, as well as
for several 32-bit filesystems mounted one under another. Note
that fts_level has to be signed because -1 is a magic value for it,
FTS_ROOTPARENTLEVEL.
o For the `nlinks' local var in fts_build(), use `long'. The logic
in fts_build() requires that `nlinks' be signed, but our nlink_t
currently is uint16_t. Therefore let's make the signed var wide
enough to be able to represent 2^16-1 in pure C99, and even 2^32-1
on a 64-bit platform. Perhaps the logic should be changed just
to use nlink_t, but it can be done later w/o breaking fts(3) ABI
any more because `nlinks' is just a local var.
This commit also inludes supporting stuff for the fts change:
o Preserve the old versions of fts(3) functions through libc symbol
versioning because the old versions appeared in all our former releases.
o Bump __FreeBSD_version just in case. There is a small chance that
some ill-written 3-rd party apps may fail to build or work correctly
if compiled after this change.
o Update the fts(3) manpage accordingly. In particular, remove
references to fts_bignum, which was a FreeBSD-specific hack to work
around the too narrow types of FTSENT members. Now fts_number is
at least 64 bits wide (long long) and fts_bignum is an undocumented
alias for fts_number kept around for compatibility reasons. According
to Google Code Search, the only big consumers of fts_bignum are in
our own source tree, so they can be fixed easily to use fts_number.
o Mention the change in src/UPDATING.
PR: bin/104458
Approved by: re (quite a while ago)
Discussed with: deischen (the symbol versioning part)
Reviewed by: -arch (mostly silence); das (generally OK, but we didn't
agree on some types used; assuming that no objections on
-arch let me to stick to my opinion)
rwatson [Sat, 26 Jan 2008 12:34:23 +0000 (12:34 +0000)]
Remove Giant acquisition around soreceive() and sosend() in fifofs. The
bug that caused us to reintroduce it is believed to be fixed, and Kris
says he no longer sees problems with fifofs in highly parallel builds.
If this works out, we'll MFC it for 7.1.
mpp [Sat, 26 Jan 2008 12:03:26 +0000 (12:03 +0000)]
Sync up quotacheck's preen.c with fsck's. This makes quotacheck
process parallel checks in the same way as fsck, since fsck supports
pass numbers other than 0, 1 or 2. Without this, quotacheck would
ignore file systems with pass numbers > 2.
The -l (maxrun) option is now deprecated and can be tuned with pass
numbers in /etc/fstab if needed.
mtm [Sat, 26 Jan 2008 11:22:12 +0000 (11:22 +0000)]
Re-implement: do not silently fail when a command is not carried
out because the rc.conf(5) variable was not enabled. Display a
message that the command wasn't run and offer suggestions on
what the user can do.
Implement a quiet prefix, which will disable some diagnostics. The
fast prefix also implies quiet. During boot we use either fast or
quiet. For shutdown we already use 'faststop'. So, this informational
message should only appear during interactive use.
An additional benefit of having a quiet prefix is that we can start
putting some of our diagnostic messages behind this knob and start
"de-cluttering" the console during boot and shutdown.
jhb [Fri, 25 Jan 2008 19:44:46 +0000 (19:44 +0000)]
Fix a bug where a thread that hit the race where the sleep timeout fires
while the thread does not hold the thread lock would stop blocking for
subsequent interruptible sleeps and would always immediately fail the
sleep with EWOULDBLOCK instead (even sleeps that didn't have a timeout).
Some background:
- KSE has a facility for allowing one thread to interrupt another thread.
During this process, the target thread aborts any interruptible sleeps
much as if the target thread had a pending signal. Once the target
thread acknowledges the interrupt, normal sleep handling resumes. KSE
manages this via the TDF_INTERRUPTED flag. Specifically, it sets the
flag when it sends an interrupt to another thread and clears it when
the interrupt is acknowledged. (Note that this is purely a software
interrupt sort of thing and has no relation to hardware interrupts
or kernel interrupt threads.)
- The old code for handling the sleep timeout race handled the race
by setting the TDF_INTERRUPT flag and faking a KSE-style thread
interrupt to the thread in the process of going to sleep. It probably
should have just checked the TDF_TIMEOUT flag in sleepq_catch_signals()
instead.
- The bug was that the sleepq code would set TDF_INTERRUPT but it was
never cleared. The sleepq code couldn't safely clear it in case there
actually was a real KSE thread interrupt pending for the target thread
(in fact, the sleepq timeout actually stomped on said pending interrupt).
Thus, any future interruptible sleeps (*sleep(.. PCATCH ..) or
cv_*wait_sig()) would see the TDF_INTERRUPT flag set and immediately
fail with EWOULDBLOCK. The flag could be cleared if the thread belonged
to a KSE process and another thread posted an interrupt to the original
thread. However, in the more common case of a non-KSE process, the
thread would pretty much stop sleeping.
- Fix the bug by just setting TDF_TIMEOUT in the sleepq timeout code and
not messing with TDF_INTERRUPT and td_intrval. With yesterday's fix to
fix sleepq_switch() to check TDF_TIMEOUT, this is now sufficient.
jhb [Fri, 25 Jan 2008 19:24:12 +0000 (19:24 +0000)]
Update the timestamp regexps in syncstamp() and monostamp() for > 99999
traces where there isn't any leading whitespace before the record number
in the ktrdump output.
mtm [Fri, 25 Jan 2008 16:44:34 +0000 (16:44 +0000)]
Backout previous commit. It's going to clutter the console
during boot and shutdown. I think I'll hide it behind autoboot or
maybe take brooks@ suggestion and implement a different command
prefix for booting/shutdown purposes, but in any case it needs more
thought and attention.
mtm [Fri, 25 Jan 2008 15:06:26 +0000 (15:06 +0000)]
If the rc.conf(5) variable for a script is not enabled do not fail
silently. Display a message that the command wasn't run and make
possible suggestions for what to do.
rwatson [Fri, 25 Jan 2008 14:38:27 +0000 (14:38 +0000)]
Hide ipfw internal data structures behind IPFW_INTERNAL rather than
exposing them to all consumers of ip_fw.h. These structures are
used in both ipfw(8) and ipfw(4), but not part of the user<->kernel
interface for other applications to use, rather, shared
implementation.
MFC after: 3 days
Reported by: Paul Vixie <paul at vix dot com>
jhb [Fri, 25 Jan 2008 02:09:38 +0000 (02:09 +0000)]
Fix a race in the sleepqueue timeout code that resulted in sleeps not
being properly cancelled by a timeout. In general there is a race
between a the sleepq timeout handler firing while the thread is still
in the process of going to sleep. In 6.x with sched_lock, the race was
largely protected by sched_lock. The only place it was "exposed" and had
to be handled was while checking for any pending signals in
sleepq_catch_signals().
With the thread lock changes, the thread lock is dropped in between
sleepq_add() and sleepq_*wait*() opening up a new window for this race.
Thus, if the timeout fired while the sleeping thread was in between
sleepq_add() and sleepq_*wait*(), the thread would be marked as timed
out, but the thread would not be dequeued and sleepq_switch() would
still block the thread until it was awakened via some other means. In
the case of pause(9) where there is no other wakeup, the thread would
never be awakened.
Fix this by teaching sleepq_switch() to check if the thread has had its
sleep canceled before blocking by checking the TDF_TIMEOUT flag and
aborting the sleep and dequeueing the thread if it is set.
dumbbell [Thu, 24 Jan 2008 17:10:19 +0000 (17:10 +0000)]
When asked to use kqueue, AIO stores its internal state in the
`kn_sdata' member of the newly registered knote. The problem is that
this member is overwritten by a call to kevent(2) with the EV_ADD flag,
targetted at the same kevent/knote. For instance, a userland application
may set the pointer to NULL, leading to a panic.
attilio [Thu, 24 Jan 2008 12:34:30 +0000 (12:34 +0000)]
Cleanup lockmgr interface and exported KPI:
- Remove the "thread" argument from the lockmgr() function as it is
always curthread now
- Axe lockcount() function as it is no longer used
- Axe LOCKMGR_ASSERT() as it is bogus really and no currently used.
Hopefully this will be soonly replaced by something suitable for it.
- Remove the prototype for dumplockinfo() as the function is no longer
present
Addictionally:
- Introduce a KASSERT() in lockstatus() in order to let it accept only
curthread or NULL as they should only be passed
- Do a little bit of style(9) cleanup on lockmgr.h
KPI results heavilly broken by this change, so manpages and
FreeBSD_version will be modified accordingly by further commits.
pjd [Thu, 24 Jan 2008 11:24:16 +0000 (11:24 +0000)]
- Reduce how much ZFS caches by default. This is another change to mitigate
'kmem_map too small panics'.
- Print two warnings if there is not enough memory and not enough address
space.
- Improve comment.
scottl [Thu, 24 Jan 2008 07:26:53 +0000 (07:26 +0000)]
Many improvements that have been collected over time:
- Improve error handling for load operations.
- Fix a memory corruption bug when using certain linux management apps.
- Allocate all commands up front to avoid OOM deadlocks later on.
trhodes [Thu, 24 Jan 2008 00:39:38 +0000 (00:39 +0000)]
Add a diagnostic note about "transmission error ... tx underrun, increasing
tx start threshold ..." Looking around on the mailing lists, and even having
one of these cards I agree the messages should be documented.
rwatson [Wed, 23 Jan 2008 21:15:51 +0000 (21:15 +0000)]
tcp_usrreq.c:1.313 removed tcbinfo locking from tcp_usr_accept(), which
while in principle a good idea, opened us up to a race inherrent to
the syncache's direct insertion of incoming TCP connections into the
"completed connection" listen queue, as it transpires that the socket
is inserted before the inpcb is fully filled in by syncache_expand().
The bug manifested with the occasional returning of 0.0.0.0:0 in the
address returned by the accept() system call, which occurred if accept
managed to execute tcp_usr_accept() before syncache_expand() had copied
the endpoint addresses into inpcb connection state.
Re-add tcbinfo locking around the address copyout, which has the effect
of delaying the copy until syncache_expand() has finished running, as
it is run while the tcbinfo lock is held. This is undesirable in that
it increases contention on tcbinfo further, but a more significant
change will be required to how the syncache inserts new sockets in
order to fix this and keep more granular locking here. In particular,
either more state needs to be passed into sonewconn() so that
pru_attach() can fill in the fields *before* the socket is inserted, or
the socket needs to be inserted in the incomplete connection queue
until it is actually ready to be used.
kientzle [Wed, 23 Jan 2008 05:47:08 +0000 (05:47 +0000)]
Explain a subtle API change that was made recently.
Even though I believe this is a good change, it does
have the potential to break certain clients, so it's
good to document the reasoning behind the change.
jeff [Wed, 23 Jan 2008 03:10:18 +0000 (03:10 +0000)]
- sched_prio() should only adjust tdq_lowpri if the thread is running or on
a run-queue. If the priority is numerically raised only change lowpri
if we're certain it will be correct. Some slop is allowed however
previously we could erroneously raise lowpri for an idle cpu that a
thread had recently run on which lead to errors in load balancing
decisions.
ache [Wed, 23 Jan 2008 01:57:26 +0000 (01:57 +0000)]
1) Add (void) cast to _none_init() (while I am here)
2) Fix longstanding segfault in mb/wc code when unknown encoding is specified
in the locale file (mb/wc functions becomes NULL in that case).