RDMA/restrack: Release task struct which was hold by CM_ID object
authorLeon Romanovsky <leonro@mellanox.com>
Tue, 2 Oct 2018 08:48:03 +0000 (11:48 +0300)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 21 Sep 2019 05:16:41 +0000 (07:16 +0200)
commit305c3b49766200398ad603b7e3c66243ba68c7f0
treea6ec728c38f92c36e84438a030bf9ede64abad0c
parent8993c673d6c418d565c47f88201e201759e00ecf
RDMA/restrack: Release task struct which was hold by CM_ID object

commit ed7a01fd3fd77f40b4ef2562b966a5decd8928d2 upstream.

Tracking CM_ID resource is performed in two stages: creation of cm_id
and connecting it to the cma_dev. It is needed because rdma-cm protocol
exports two separate user-visible calls rdma_create_id and rdma_accept.

At the time of CM_ID creation, the real owner of that object is unknown
yet and we need to grab task_struct. This task_struct is released or
reassigned in attach phase later on. but call to rdma_destroy_id left
this task_struct unreleased.

Such separation is unique to CM_ID and other restrack objects initialize
in one shot. It means that it is safe to use "res->valid" check to catch
unfinished CM_ID flow and release task_struct for that object.

Fixes: 00313983cda6 ("RDMA/nldev: provide detailed CM_ID information")
Reported-by: Artemy Kovalyov <artemyko@mellanox.com>
Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com>
Reviewed-by: Yossi Itigin <yosefe@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Cc: HÃ¥kon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/infiniband/core/cma.c
drivers/infiniband/core/restrack.c