Skip to content

few nvme-rdma fixes for 4.18

Christoph Hellwig linux-nvme 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest2 of 7 patches 0 repliesNew

2 of 7 patches are in this archive. The cover letter announces 7.

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/7nvme-rdma: fix possible double free condition when failing to create a controller+0 -00 replies
2/7nvme-rdma: fix possible free non-allocated async event buffer+0 -04 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 0/7] few nvme-rdma fixes for 4.18
Quoted 15 lines · Sagi Grimberg
Quoted 7 lines
Quoted 3 lines

4 is needed to prevent a theoretical hang in controller removal, but never encountered.

This one I'm indeed a little concerned about as I remember various issues in this area in PCIe. And RDMA is just different enough that it doesn't look very similar.

Actually, 4 follows PCIe one to one:
--
/*
* The driver will not be starting up queues again if shutting down
so
* must flush all entered requests to their failed completion to
avoid

Quoted 7 lines
         * deadlocking blk-mq hot-cpu notifier.
         */
        if (shutdown)
                nvme_start_queues(&dev->ctrl);

--
Nothing about this is PCIe specific, its about the controller going away with quiesced IO.

With the difference that PCIe does it at the end of nvme_dev_disable, long after we've actually disabled or shut down the controller, while RDMA does it before shutting down the controller.

Quoted 5 lines

On a side note, If you look at nvme_reset_work and nvme_dev_disable, its not that different from what RDMA does, its just arranged slightly different. I'm still very much think that PCIe and RDMA and FC (and TCP) can have the same probe, reset, remove sequences. I guess it will just take some more time to get there.

Sharing more code would be great, especially for managing the block layer state.