Page MenuHomeFreeBSD

nvme: complete requests when payload DMA mapping fails
ClosedPublic

Authored by seuros on Mon, Aug 24, 6:19 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Sep 8, 2:36 PM
Unknown Object (File)
Tue, Sep 8, 1:03 PM
Unknown Object (File)
Tue, Sep 8, 4:36 AM
Unknown Object (File)
Mon, Sep 7, 11:08 PM
Unknown Object (File)
Mon, Sep 7, 10:28 PM
Unknown Object (File)
Mon, Sep 7, 8:30 PM
Unknown Object (File)
Mon, Sep 7, 2:49 PM
Unknown Object (File)
Sun, Sep 6, 9:21 PM
Subscribers

Details

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.

Approved by: ngie (co-mentor)
MFC after: 1 week

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 76056
Build 72939: 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.

imp added inline comments.
sys/dev/nvme/nvme_qpair.c
1217

OK. The callback is always called, so this is good.

This revision is now accepted and ready to land.Tue, Sep 1, 7:43 PM

Approved by: ngie (co-mentor)