New test case that reflects the fix in PR kern/57260. The majority of
work for this case itself was by riastradh@, who'd supplied the basis
for it in the ticket, and provided further guidance.
All the members these use are stable after initialization, except for
the wedge size, which dkwedge_size safely reads a snapshot of without
locking in the caller.
This way, opening dkN or rdkN will wait if attach or detach is still
in progress, and vdevgone will wake up such pending opens and make
them fail. So it is no longer possible for a wedge to be detached
after dkopen has already started using it.
For now, we use a custom .d_devtounit function that looks up the
autoconf unit number via the dkwedges array, which conceivably may
use an independent unit numbering system -- nothing guarantees they
match up. (In practice they will mostly match up, but concurrent
wedge creation could lead to different numbering.) Eventually this
should be changed so the two numbering systems match, which would let
us delete the new dkunit function and just use dev_minor_unit like
many other drivers can.
The first step is to decide whether we can detach (if forced, yes; if
not forced, only if not already open), and prevent new opens if so.
There's no need to start closing open instances at this point --
we're just making a decision to detach, and preventing new opens by
transitioning state that dkopen will respect[*].
The second step is to force all open instances to close. This is
done by vdevgone. By the time vdevgone returns, there can be no open
instances, so if there _were_ any, closing them via vdevgone will
have passed through dklastclose.
After that point, there can be no opens and no I/O operations, so
dk_openmask must already be zero and the bufq must be empty.
Thus, there's no need to have an explicit call to dklastclose (via
dkwedge_cleanup_parent) before or after making the decision to
detach.
[*] Currently access to this state is racy: nothing serializes
dkwedge_detach's state transition with dkopen's test. TBD in a
separate commit shortly.
1. Set a flag sc_iostop under the lock sc_iolock so dkwedge_detach
and dkstart don't race over it.
2. Decline to schedule the callout if sc_iostop is set. The callout
is already only ever scheduled while the lock is held.
3. Use callout_halt to wait for any concurrent callout to complete.
At this point, it can't reschedule itself.
Without this change, the callout could be concurrently rescheduling
itself as we issue callout_stop, leading to use-after-free later.
This way, dkclose is guaranteed that dkopen, dkread, dkwrite,
dkioctl, &c., have all returned before it runs. For block opens,
setting d_cancel also guarantees that any buffered writes are flushed
with vinvalbuf before dkclose is called.
This can happen with dk(4), which allows wedges to have their size
increased without destroying and recreating the device instance.
Drivers which allow concurrent disk_set_info and disk_ioctl must
serialize disk_set_info with dk_openlock.
Follows the pattern of most drivers, and will be necessary for
referencing dk_cd in dk_bdevsw and dk_cdevsw soon, to prevent
open/detach races.
No functional change intended.
Rules:
1. Only ever increases, never decreases.
(Decreases require removing and readding the wedge.)
2. Increases are serialized by dk_openlock.
3. Reads can happen unlocked in any context where the softc is valid.
Access is gathered into dkwedge_size* subroutines -- don't touch
sc_size outside these. For now, we use rwlock(9) to keep the
reasoning simple. This should be done with atomics on 64-bit
platforms and a seqlock on 32-bit platforms to avoid contention.
However, we can do that in a later change.
ENXIO is `device not configured', meaning there is no such device.
ENODEV is `operation not supported by device', meaning the device is
there but refuses the operation, like writing to a read-only medium.
Exception: For undefined ioctl commands, it's not ENODEV _or_ ENXIO,
but rather ENOTTY, because why make any of this obvious when you
could make it obscure Unix lore?
This is not great -- we shouldn't be choosing the unit number here
anyway; we should just let autoconf do it for us -- but it's better
than potentially blocking any dk_openlock or dk_rawlock (which are
sometimes held when waiting for dkwedges_lock) for memory allocation.
We only enter dklastclose if the wedge is open (sc->sc_dk.dk_openmask
!= 0), which can happen only if dkfirstopen has succeeded, in which
case we hold a dk_rawopens reference to the parent that prevents
anyone else from closing it. Hence sc->sc_parent->dk_rawopens > 0.
On open, sc->sc_parent->dk_rawvp is set to nonnull, and it is only
reset to null on close. Hence if the parent is still open, as it
must be here, sc->sc_parent->dk_rawvp must be nonnull.
* privsep: keep resources open rather than open/close
* dhcp6: OPTION_NTP_SERVER is now preferred over OPTION_SNTP_SERVER
* Misc bug fixes mainly around privsep for many platforms.
* Fix for reading the some BSD routing table entries.
* Fix reading authtokens from config.
Big new release, mainly around better privsep process management
which allows us to detect when they exit unexpectedly.
This prevents the following race condition.
1. Thread-A: calls virtio_dequeue_commit() and
puts a slot into free descriptor chain in vq_free_slot()
2. Thread-B: calls virtio_enqueue_prep() and get the slot stored by Thread-A
3. Thread-B: calls virtio_enqueue_reserve() and
changes desc_base and desc_free_idx for the slot
4. Thread-A: changes the same members updated by Thread-B
reported by hannken, thanks.
basename(3) is invoked more than once on different paths. Retain the
correct name for the utility itself on error. Addresses PR bin/57355
from RVP, who provided the patch.
skrll