few nvme-rdma fixes for 4.18
Get series with b4
b4 am [email protected]Versions newest first
- 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 files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/7 | nvme-rdma: fix possible double free condition when failing to create a controller | +0 | 0 replies | |
| 2/7 | nvme-rdma: fix possible free non-allocated async event buffer | +0 | 4 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
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_workandnvme_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.