running" panics.
Previously, recursion through the "include" feature was prevented by
marking each ruleset as "running" when applied. This doesn't work for
the case where two DEVFS instances try to apply the same ruleset at
the same time.
Instead introduce the sysctl vfs.devfs.rule_depth (default == 1) which
limits how many levels of "include" we will traverse.
Be aware that traversal of "include" is recursive and kernel stack
size is limited.
MFC: after 3 days
that with the NIC set of registers rather than the ASIC registers. I
believe this was a harmless oversight, since we set ED_P0_CR to the
same value 5ms later, but just to be safe...
it is destroyed in GEOM, in addition to being removed from /dev.
Before this patch, if you applied a new MBR which deleted a slice,
the deleted slice would not be in /dev, but it would still appear
in kern.geom.conftxt and kern.geom.confxml, which would confused
the diskPartitionEditor in sysinstall.
Submitted by: pjd
Tested by: pjd, rodrigc
MFC after: 1 week
linked process was exec()'ed, and map samples in that address range
into the appropriate buckets in the runtime loader's profile.
Improve a few comments.
MFC after: 3 days
just use MAXPATHLEN. It prevents potential buffer overflow with other
malloc implementations.
(this change based on submitted patch)
PR: 86135
Submitted by: Trevor Blackwell <tlb@tlb.org>
risky because the "current time" is supposed to be fed to the card during
initialization, and the current time is supposed to be put into each command
that is sent to the card. Hopefully either the card doesn't actually care
about the timestamps, or it doesn't care about the absolute values so long
and the relative values are consistent. Not an MFC candidate until more
thorough testing can be done.
While I'm here add KASSERT(9) to notify failure of SYSUNINIT handler.
Reported by: Ben Kaduk < minimarmot AT gmail DOT com >
Tested by: Ben Kaduk < minimarmot AT gmail DOT com >
o Attach AX88x90's MII bus to system, and require its presence.
o Reorg the mii code a little, and move more of it into pccard attachment.
o Eliminate ed_pccard_{read,write}_attrmem in favor of a more appropriate
function in the pccard layer.
o Update comments to reflect knowledge gained.
o Update how re recognize a NE-2000 ROM. I found a couple of different
datasheets that define the structure of the PROM data, so the code's
old heuristics have been removed, and comments updated to reflect the
structure.
o Eliminate work around for EC2T. It is no longer needed, and was wrong
headed since the EC2T has a Winbound 82C926C in it, not a AX88x90.
o Add copyright to if_ed_pccard.c, since I believe I've re-written more than
3/4 of it.
# With these changes, all of my 20-odd ed based cards work, except for the
# NetGear FA-410, and I'm pretty sure that's a MII/PHY problem.
at LOG_WARNING by default; instead, consider it something to be printed
to the tty when 'verbose' mode is set. This avoids printing out extra
lines at every boot on a system with crash dumps enabled, but that has
not yet had to generate a crashdump.
MFC after: 1 week
attach to. These cards are combo cards (in that they have a modem
inside of them), but not true MFC cards. Full support of these cards
will have to wait until we can pick the config to use and for the PFC
support that I have brewing.
fifo_kqfilter() VOP implementations, since they in theory are used
only on open file descriptors, in which case the ioctls are via
fifo_ioctl_f() and kqueue requests are via fifo_kqfilter_f().
Generate warnings if they are entered for now. These printf()
calls should become panic() calls.
Annotate and re-implement fifo_ioctl_f(): don't arbitrarily
forward ioctls to the socket layer, only forward the ones we
explicitly support for fifos. In the case of FIONREAD, don't
forward the request to the write socket on a read-write fifo, or
the read result is overwritten. Annotate a nasty case for the
undefined POSIX O_RDWR on fifos, in which failure of the second
ioctl will result in the socket pair being in an inconsistent
state.
Assert copyright as I find myself rewriting non-trivial parts of
fifofs.
MFC after: 3 days
relating to O_RDWR file descriptors, which while not defined in POSIX,
are in fact used:
(1) Revise assumption that we have two file descriptors when testing I/O
operations on a fifo. Provide cleanup routines that handle either
two or three file descriptors (including a kqueue descriptor).
(2) Add an openfifo_rw() routine to supplement openfifo().
(3) kqueue_setup() now configures an existing kqueue to monitor a new
file descriptor, rather than allocating a new kqueue to monitor two
existing file descriptors.
(4) Wrap all direct poll/select/kqueue/FIONREAD interactions in a single
function, assert_status(), which takes a file descriptor, kqueue
descriptor, assertion of read/writable/exception states, and
test description, then tests the assertion. This reduces the bulk
of calls in many of the tests, making them shorter, more readable,
and easier to determine correct.
(5) Add a new test_events_rdwr() function, which performs a basic create/
write/read event test on a O_RDWR fifo file descriptor. This is
currently failed by our fifo code in HEAD due to a bug in FIONREAD
handling. Fix to be merged shortly.
- Replace 'process' with 'thread' everywhere.
- Update several places to note that that the fact that default mutexes
may adaptively spin isn't necessarily MD, but is just part of the
implementation as a whole.
- Clarify the text about MTX_SPIN mutexes only being appropriate for
INTR_FAST interrupts or other low level scheduler code to make the
jargon more FreeBSD-ish rather than BSD/OS-ish.
- Also, note that it is possible that interrupts aren't blocked but just
deferred when a spin lock is held (the whole blocked vs. deferred bit is
an MD implementation detail).
- Remove statements saying that spin locks must be released in the exact
opposite order that they were acquired. This stopped being true several
years ago when we first added critical sections that stored their state
in the current thread rather than in struct mtx.
- Note that a mutex must be initialized before it is passed to any other
mutex function, not just mtx_lock.
- Clarify that mtx_trylock() only operates on MTX_DEF mutexes.
- Simplify the text about possible preemption during a mtx_unlock().
- Use complete English sentences in place of phrases in a few places.
- Clarify that it isn't ever safe to sleep with a mutex held. The kernel
tends to panic when you do that.
Requested by: scottl (7)
MFC after: 3 days
