Page MenuHomeFreeBSD

nvme: complete requests when payload DMA mapping fails
Needs ReviewPublic

Authored by seuros on Mon, Aug 24, 6:19 PM.
Tags
None
Referenced Files
F168788263: D59151.diff
Sun, Aug 30, 4:04 AM
F168770491: D59151.id184919.diff
Sun, Aug 30, 1:53 AM
F168764561: D59151.diff
Sun, Aug 30, 1:07 AM
F168703545: D59151.diff
Sat, Aug 29, 5:33 PM
Unknown Object (File)
Sat, Aug 29, 1:20 PM
Unknown Object (File)
Sat, Aug 29, 1:18 PM
Unknown Object (File)
Sat, Aug 29, 6:07 AM
Unknown Object (File)
Sat, Aug 29, 3:46 AM
Subscribers

Details

Reviewers
adrian
imp
Summary

bus_dmamap_load_mem() reports most mapping failures, including EFBIG,
only through its callback and then returns zero. nvme_payload_map()
logged the error without telling the submission path, so the tracker
stayed on the outstanding list with no command submitted and no
timeout armed, stalling all later I/O on the queue behind it.

MFC after: 2 weeks

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 76110
Build 72993: arc lint + arc unit

Event Timeline

sys/dev/nvme/nvme_qpair.c
1181

Should we set this to EINPROGRESS here? Are there paths out which don't do the DMA that aren't a mapping failure?

1200

I'd think that we don't want to wait here.
If it's just to detect this error, can't we detect it in the callback instead?

ngie added inline comments.
sys/dev/nvme/nvme_qpair.c
1200

+1. Doing this in the callback (if possible) seems much cleaner so you don't have to deal with the truth table of err x tr->map_err conditional combinations and the associated complexity in all of the downstream callers.