Page MenuHomeFreeBSD

nvme: Allow command opcodes with lower bit clear as reads
ClosedPublic

Authored by imp on Apr 29 2025, 5:15 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Oct 1, 10:39 AM
Unknown Object (File)
Wed, Sep 24, 4:18 PM
Unknown Object (File)
Sat, Sep 20, 10:47 PM
Unknown Object (File)
Fri, Sep 19, 7:27 PM
Unknown Object (File)
Fri, Sep 19, 7:00 AM
Unknown Object (File)
Thu, Sep 18, 6:28 AM
Unknown Object (File)
Sep 13 2025, 12:15 AM
Unknown Object (File)
Sep 8 2025, 6:21 AM
Subscribers

Details

Summary

Linux does this, and nvme-cli has some vendor specific opcodes that need
this.

Sponsored by: Netflix

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

imp requested review of this revision.Apr 29 2025, 5:15 AM
sys/dev/nvme/nvme_ctrlr.c
1371

So now when the OP code's data transfer field says there is no data and this is a "user command" (all the instances of nvme_ctrlr_linux_passthru_cmd() appear to set this to true), the driver is going to allocate npc->data_len worth of memory? Any concerns about the value of data_len potentially being set for a command that wouldn't normally transfer data?

sys/dev/nvme/nvme_ctrlr.c
1371

Given that Linux would not have these, and most of the passthru code is written for Linux and Linux behaves this way, I'd think any errors like this would be caught.
And if not, there'd be an error completion code for this sort of opcode.
Also, the drive would fail with NVME_SC_DATA_TRANSFER_ERROR if we didn't read data tthat should be there, or tried to read data that wasn't.
So I think we'd fail safe.

This revision is now accepted and ready to land.Apr 30 2025, 10:18 PM