Kernel maintainers add dm-inlinecrypt, NVMe counters and io_uring ZCRX fixes for Linux 7.2
#Infrastructure

Kernel maintainers add dm-inlinecrypt, NVMe counters and io_uring ZCRX fixes for Linux 7.2

Hardware Reporter
6 min read

Linux 7.2 storage work gives NVMe admins more controller data, gives io_uring users cleaner zero-copy receive signals and gives UFS systems a Device Mapper path for inline encryption.

{{IMAGE:2}}

Kernel storage maintainers merged a large Linux 7.2 batch covering NVMe, block, MD RAID, io_uring and Device Mapper. The work touches admin visibility, peer-to-peer DMA paths, RAID error handling, zero-copy networking and inline encryption.

The Linux 7.2 merge window runs through June 28, 2026, so this storage set lands while subsystem maintainers still feed feature branches into Linus Torvalds' tree. You can track the mainline source through kernel.org and the kernel documentation through docs.kernel.org.

Product: Linux 7.2 storage stack

The NVMe changes add per-controller admin and I/O timeout sysfs attributes. Operators who tune mixed fleets get a cleaner path to inspect controller behavior without relying on vendor tools or broad kernel logs.

NVMe also gains PCI peer-to-peer DMA support for multipath devices. P2PDMA lets one PCIe device move data to another PCIe device without routing that payload through host memory. In storage servers with GPUs, smart NICs or accelerators near NVMe devices, that path can cut memory bandwidth pressure and shave latency in workloads that move large buffers between devices.

The new per-controller counter group in sysfs gives admins another way to inspect controller state. That matters in homelab and fleet setups where two drives with the same model string can behave differently because firmware, topology or thermal limits differ.

Device Mapper gets the headline encryption change: dm-inlinecrypt. The target gives Linux a DM path for hardware inline block encryption, with UFS host controllers as a key use case. dm-crypt still handles the broad software encryption role, while dm-inlinecrypt targets controllers that can encrypt data in the storage path.

io_uring receives a task_work rework, registered-buffer improvements, zero-copy receive user notifications and opcode filtering for IORING_OP_CONNECT. Developers who build high-throughput servers should read the io_uring documentation before they wire these paths into production code.

Performance data: where the wins should show up

Linux maintainers did not publish benchmark numbers in the merge summary, so builders should test against their own kernels and devices. The patch areas still point to clear measurement targets.

Area Linux 7.2 change Benchmark to run Metric to watch
NVMe multipath P2PDMA enablement fio with multipath namespaces p99 latency, CPU use, memory bandwidth
io_uring task_work rework fixed-buffer network service test requests per second, context switches
io_uring ZCRX user notifications through CQE receive-heavy TCP test copy rate, CQ depth, tail latency
MD RAID1/RAID10 read error recovery fixes degraded-array read test recovery time, blocked I/O time
Device Mapper dm-inlinecrypt UFS inline encryption test CPU use, write latency, sustained throughput

On NVMe boxes, start with fio. Run a baseline on Linux 7.1 or your current 7.2-rc baseline, then boot a kernel that includes the new storage merges. Keep queue depth, block size, CPU governor, NUMA binding and filesystem mount options constant. For P2PDMA tests, place devices under the same PCIe root complex when your platform allows it.

For io_uring, benchmark the application path instead of a synthetic syscall loop. The task_work changes target overhead inside the completion and work scheduling machinery. You should see the effect in a server that keeps many sockets busy, uses registered buffers and spends little time in user-space business logic.

ZCRX user notifications through a dedicated completion queue entry give applications a cleaner signal path after zero-copy receive work completes. That improves accounting and buffer recycling logic. Measure dropped packets, CQ overflow and buffer reuse delays under load.

Power consumption: encryption and data movement matter

Storage power tests need wall power and device telemetry. A kernel change that cuts CPU copies can reduce package power while raising device activity. You need both views.

For NVMe P2PDMA, watch CPU package watts, DRAM power if your platform exposes it and SSD temperature. A peer-to-peer path can save host memory traffic, but a busy SSD can still hit thermal throttling. Run a 30-minute sustained test, not a two-minute burst.

For dm-inlinecrypt, compare inline encryption against dm-crypt on the same UFS device. Hardware inline encryption should reduce CPU cycles per gigabyte. The practical win depends on controller support, keyslot behavior and workload mix.

For io_uring ZCRX, use RAPL on Intel or AMD energy counters where available, plus NIC telemetry. If zero-copy receive reduces CPU package power but your application adds buffer bookkeeping overhead, the net result can shrink. Measure the full service, not the API call.

Compatibility: check sysfs, controller support and kernel config

The NVMe sysfs additions help admins inspect controller settings, but scripts must tolerate kernels that lack the new attributes. Fleet tooling should probe for each file before reading it.

P2PDMA depends on PCIe topology and device support. Multipath does not guarantee peer-to-peer transfers. Builders should map the PCIe tree with lspci, check ACS behavior and test each path under load.

MD RAID1 and RAID10 fixes address a deadlock in the read error recovery path and improve P2PDMA propagation from member devices to the RAID device. Anyone running mixed NVMe RAID sets should include degraded-array tests in validation, since error paths expose bugs that clean benchmarks miss.

Device Mapper users need hardware that supports inline encryption before dm-inlinecrypt can help. UFS systems gain the clearest path here. NVMe and SATA users should verify controller capabilities before planning around this target.

io_uring applications need kernel support, liburing coverage and application logic that handles the new completion behavior. The official liburing repository remains the best place to track user-space support.

Twitter image

Build recommendations

Homelab builders should treat Linux 7.2 storage as a test-kernel release until release candidates settle. Run it on a spare boot environment first, then test the exact path you care about: NVMe multipath, MD RAID recovery, UFS encryption or io_uring networking.

For NVMe servers, add sysfs collection to your telemetry stack. Record controller counters, timeouts, SMART data, PCIe link width and drive temperature during fio runs. The new per-controller counters will help you spot one controller that stalls while the rest of the pool looks healthy.

For RAID boxes, run fault injection. Pull a member, force read errors where your lab setup permits it and watch recovery under concurrent reads. The RAID1 and RAID10 fixes target read error recovery, so clean-array throughput will not tell you enough.

For encryption tests, compare three modes: plain block device, dm-crypt and dm-inlinecrypt. Keep filesystem, mount options and writeback settings constant. If dm-inlinecrypt cuts CPU use without hurting latency, UFS laptops and embedded boards should benefit.

For io_uring services, pin down buffer lifetime before you chase throughput. Registered buffers and ZCRX can move a service from syscall overhead to memory ownership bugs. Add counters for CQE types, buffer recycle failures and connection opcodes filtered through IORING_OP_CONNECT.

Linux 7.2 gives storage builders more knobs and better visibility. The practical wins will depend on platform layout, controller firmware and application design, so measure before you ship the kernel across a fleet.

Comments

Loading comments...