ahci - Properly check and set SATA capabilities and features for ALPM.
- This should now only enable device-initiated and/or host-initiated link
power-management when it is supported by both controller and disk device.
- Also this now allows for device-initiated power-management to be enabled
with AHCI controllers that don't support automatic host-initiated
power-management.
- In addition, this adds support for automatic promotion of "partial" state
to "slumber" state (i.e. without needing to go through "active" state).
- The kernel console output now explicitly tells when it's enabling DIPM
(device-initiated power management) and HIPM (host-initiated power
management) respectively.
wlan - Remove NULL free in fallback "none" ratectl code.
This avoids a kernel panic when detaching a wlan interface that was created
with the "none" ratectl code (i.e. when the wlan_amrr module wasn't loaded).
hammer2 - Add debugging
* Debug situations where the CRC fails. Print enough information
for us to poke around and compare the in-kernel buffer against
the disk buffer.
All instances to date where hammer2 has detected CRC corruption
has been due to in-memory corruption, source as yet undetermined.
* Usually hammer2 refuses to operate on the file/directory in
question until the buffer cache buffer with the in-memory error
is recycled or the machine is rebooted, avoiding corruption.
But it is possible that hammer2 might miss an in-memory
corruption event in some instances (occurring after the CRC
check, for example).
kernel - Handle race in vfsync_bp() and nfs_flush_bp()
* The RB_SCAN callback code on the clean/dirty buffer trees
must bump b_refs temporarily when issuing a blocking lock
to prevent the buffer from being ripped out from under the
call, as the vnode token will be lost during the blocking
operation.
* vfsync_bp() and vfs_flush_bp() omitted the required refs.
* Code cleanup.
kernel - Fix race in brelvp() and reassignbuf()
* brelvp() can be called with just the buffer (bp) locked. The
vnode might not be locked or referenced at the time brelvp()
is called, or might be locked by some other entity at the time.
* brelvp() obtains the vnode token but this is not sufficient.
There is a race where, once the bp is removed from the vnode lists,
the related vnode might be retired out from under brelvp() if the
vp token is temporarily lost.
The token can, in fact, be temporarily lost during the syncer list
manipulation at the end of the routine. Fix with a vhold()/vdrop()
around the related code.
* In addition, set bp->b_vp to NULL before the syncer_list manipulation
instead of after, ensuring that it is NULL'd out while the vnode token
is still atomically held. It was theoretically ok before since the
bp should be locked, but the lost vnode token atomicy was concerning
[3 lines not shown]
opencrypto - remove in-kernel crypto(9) framework
The opencrypto crypto(9) API was quite complex (8k LoC), slow and not
used by any other kernel subsystem within DragonFly anymore. It allowed
for chaining various operations, crypto ops and compression, but AFAIK
this was never really used and rather complicated. For a much simpler,
synchronous API see sys/src/crypto/cryptoapi. For a nice writeup on the
problems of crypto(9) in the context of FreeBSD, please see [1].
The opencrypto API was asynchronous by design. This was good back in the
days when dedicated hardware crypto devices did exist to help offload
the CPU. But the world has now changed towards synchronous CPU
instructions like AESNI. These dedicated CPU instructions are best
called synchronously, which removes the need for book-keeping of
asynchronous requests, often greatly simplifying the caller as well as
the API and "backend" implementation.
Furthermore, those dedicated crypto CPU instructions are not limited to
the kernel, they can be directly used by userland applications as well.
[15 lines not shown]
cryptodev: remove /dev/crypto pseudo-device
Remove the /dev/crypto pseudo-device. OpenBSD, which invented this API,
did this step back in release 5.7 (2015).
Note that this commit only removes the userland-facing /dev/crypto
device while still keeping the in-kernel crypto(9) API as-is. The plan
is to finally remove crypto(9) in a future commit.
The only applications within DragonFly that ever made use of /dev/crypto
were tcplay(8), cryptsetup(8) and cryptdisks(8) via libtcplay. But this
dependency on /dev/crypto was dropped in commit
ede102cd94449fe52fa9da25631d9f15af6d62ef as of April 21, 2025 in favor
of doing the crypto operations directly in userland without any help
from the kernel via /dev/crypto.
Userland libraries or applications like OpenSSH and OpenSSL do not use
/dev/crypto, mainly for performance reasons (and portability).
kernel - Do readonly check in .d_open method in mmcsd(4) and virtio_blk(4).
* Makes read-write open fail properly for read-only storage in mmcsd(4) and
virtio_blk(4), instead of only resulting in transfer errors for the
disk writes.
syscons - Add 16bit rendering code for UEFI and KMS driver framebuffers.
This fixes syscons rendering with KMS graphics drivers, when the driver
hands us a 16bit console framebuffer.
virtio_blk - Enable D_KVABIO API.
This should avoid some unnecessary page invalidations.
This driver already was compliant, since it never accesses any of the data
in the bio buffer.
