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
be held when entering a kqueue filter for fifos via a socket buffer
event: as such, assert the lock unconditionally rather than acquiring
it conditionall.
MFC after: 3 days
1) fifo_kqfilter() is not actually ever used, it likely should be GC'd.
2) fifo_kqfilter_f() doesn't implement EVFILT_VNODE, so detecting events
on the underlying vnode for a fifo no longer works (it did in 4.x).
Likely, fifo_kqfilter_f() should forward the request to the VFS using
fp->f_vnode, which would work once fifo_kqfilter() was detached from
the vnode operation vector (removing the fifo override).
Discussed with: phk
used when a read filter is requested on a write-only fifo descriptor, or
a write filter is requested on a read-only fifo descriptor. This
permits the filters to be registered, but never raises the event, which
causes kqueue behavior for fifos to more closely match similar semantics
for poll and select, which permit testing for the condition even though
the condition will never be raised, and is consistent with POSIX's notion
that a fifo has identical semantics to a one-way IPC channel created
using pipe() on most operating systems.
The fifo regression test suite can now run to completion on HEAD without
errors.
MFC after: 3 days
Add test_kqueue(), which registers and unregisters various kqueue filter
types on a fifo in order to make sure that EVFILT_READ, EVFILT_WRITE can
be registered, and that EVFILT_NETDEV can't be registered. For now, we
don't test that EVFILT_VNODE can be registered on fifos, as that has been
broken at some point.
- Remove an assertion in sound.c, it's not needed (and causes a panic now).
From the conversation via mail between glebius and Ariff:
---snip---
> Well, but which mutex protects now? Do we own anything else
> in pcm_chnalloc()? I see some queue(4) macros in pcm_chnalloc(),
> they should be protected, shouldn't they?
Queue insertion/removal occur during
1) driver loading (which is pretty much single thread /
sequential) or unloading (mutex protected, bail out if there is
any channel with refcount > 0 or busy).
2) vchan_create()/destroy(), (which is *sigh* quite complicated), but
somehow protected by 'master'/parent channel mutex. Other
thread cannot add/remove vchan (or even continue traversing
that queue) unless it can acquire parent channel mutex.
---snip---
Fix the locking in dsp.c to prevent a LOR (AFAIK not on the LOR page).
Submitted by: Ariff Abdullah <skywizard@MyBSD.org.my>
Tested with: INVARIANTS[1] and DIAGNOSTICS[2]
Tested by: netchild [1,2], David Reid <david@jetnet.co.uk> [1]
- Teach fifo_io about kqueue monitoring of fifo file descriptor status,
and add test cases for kqueue to match existing case for poll and
select. Add a new cleanup routine, cleanfifokq(), for use in tests that
use kqueues. kqueue_setup() sets up kqueue sessions, and kqueue_status()
returns file descriptor status.
- Correct a bug in select handling relating to the nfds argument, which
was incorrect so resulted in select occuring on the wrong file descriptor,
and possible false positive/negative results.
- Clarify error reporting in one byte write+read tests to distinguish
errors in the after case from the before case.
'buffers' pending NMIs from multiple interrupting PMCs and delivers
them serially.
Reported by: Olivier Crameri <olivier.crameri@epfl.ch>
MFC after: 3 days
according to POSIX, not to mention the fact that it doesn't make sense
(and hence isn't really implemented). This causes the fifo_misc
regression test to succeed.
that don't obviously fit into create, open, and io. For now, add only a
regression test to make sure that lseek() fails with ESPIPE (which it
doesn't).
file descriptor. Otherwise, the read end of a fifo might return that it
is writable (which it isn't).
Only poll the fifo for write events if the fifo attached to a writable
file descriptor. Otherwise, the write end of a fifo might return that
it is readable (which it isn't).
In the event that a file is FREAD|FWRITE (which is allowed by POSIX, but
has undefined behavior), we poll for both.
MFC after: 3 days
to poll the write socket for, the fifo polling code proceeded to poll
for the complete set of events. Use 'levents' instead of 'events' as
the argument to poll, and only poll the write socket if there is
interest in write events.
MFC after: 3 days
while sleeping to allocate fifo state: due to using the vnode lock to
serialize access to a fifo during open, it shouldn't happen (tm).
MFC after: 3 days
