nvmet-rdma: Fix possible NULL deref when handling rdma cm events
authorBart Van Assche <bart.vanassche@sandisk.com>
Tue, 1 Nov 2016 16:36:46 +0000 (18:36 +0200)
committerSagi Grimberg <sagi@grimberg.me>
Mon, 14 Nov 2016 00:08:50 +0000 (02:08 +0200)
When we initiate queue teardown sequence we call rdma_destroy_qp
which clears cm_id->qp, afterwards we call rdma_destroy_id, but
we might see a rdma_cm event in between with a cleared cm_id->qp
so watch out for that and silently ignore the event because this
means that the queue teardown sequence is in progress.

Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
drivers/nvme/target/rdma.c

index f8d23999e0f2c28b98934c6a790b3a6c2bde26d1..cf60759cc169e17fbff58c147061d3e5cffd26a2 100644 (file)
@@ -1352,7 +1352,13 @@ static int nvmet_rdma_cm_handler(struct rdma_cm_id *cm_id,
        case RDMA_CM_EVENT_ADDR_CHANGE:
        case RDMA_CM_EVENT_DISCONNECTED:
        case RDMA_CM_EVENT_TIMEWAIT_EXIT:
-               nvmet_rdma_queue_disconnect(queue);
+               /*
+                * We might end up here when we already freed the qp
+                * which means queue release sequence is in progress,
+                * so don't get in the way...
+                */
+               if (queue)
+                       nvmet_rdma_queue_disconnect(queue);
                break;
        case RDMA_CM_EVENT_DEVICE_REMOVAL:
                ret = nvmet_rdma_device_removal(cm_id, queue);