nvme/nvmf: Add NVME_GET_CONTROLLER_DATA ioctl to fetch cached cdata
ClosedPublic
Actions

Authored by jhb on Dec 27 2024, 8:29 PM.

Details

Reviewers

imp
chuck
dab

Commits

rG4298ce72f650: nvme/nvmf: Add NVME_GET_CONTROLLER_DATA ioctl to fetch cached cdata

Summary

Both nvme and nvmf cache a copy of the controller's identify data in
the softc. Add an ioctl to fetch this copy of the cdata. This is
primarily useful for allowing commands like 'devlist' to work against
a disconnected Fabrics host.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 61432
Build 58316: arc lint + arc unit

Event Timeline

jhb created this revision.Dec 27 2024, 8:29 PM

Herald added a subscriber: dab. · View Herald TranscriptDec 27 2024, 8:29 PM

jhb requested review of this revision.Dec 27 2024, 8:29 PM

Harbormaster completed remote builds in B61357: Diff 148443.Dec 27 2024, 8:29 PM

jhb added a child revision: D48219: nvmf: Add NVMF_CONNECTION_STATUS ioctl.Dec 27 2024, 8:29 PM

imp added inline comments.Dec 27 2024, 8:46 PM

sbin/nvmecontrol/nvmecontrol.c
103 ↗	(On Diff #148443)	Maybe it uglifies the code, but do we want to have a force a pass through command option and path? It would be useful for debugging in case ident changes and the driver fails to update its cache.
sys/dev/nvme/nvme_ctrlr.c
1447	Copyout maybe?
sys/dev/nvmf/host/nvmf.c
1099	Copyout maybe?

jhb added inline comments.Dec 27 2024, 8:54 PM

sbin/nvmecontrol/nvmecontrol.c
103 ↗	(On Diff #148443)	I wondered if there were cases where we would want to always use pass through or not. I could instead restructure the devlist handler to use this ioctl in the case that a fabrics controller is disconnected and leave this path as-is. It wasn't clear to me if there were any cases where the cdata could change or if it was effectively read-only.
sys/dev/nvmf/host/nvmf.c
1099	It's an ioctl, the buffer is already in kernel memory.

imp added inline comments.Dec 27 2024, 9:33 PM

sys/dev/nvmf/host/nvmf.c
1099	It's a pointer that's copied into the kernel with the usual ioctl routine. The ident size is bigger than can be encoded on the ioctl cmd. So memcpy works because the kernel and user space are mapped at rhe same time on x86_64. Or am I missing something?