diff options
author | Leon Romanovsky | 2018-10-02 10:48:03 +0200 |
---|---|---|
committer | Jason Gunthorpe | 2018-10-06 00:07:39 +0200 |
commit | ed7a01fd3fd77f40b4ef2562b966a5decd8928d2 (patch) | |
tree | f8d97bcf113c3b66db0d88632334cfc55d7ef9f4 /drivers/acpi/processor_driver.c | |
parent | RDMA/restrack: Consolidate task name updates in one place (diff) | |
download | kernel-qcow2-linux-ed7a01fd3fd77f40b4ef2562b966a5decd8928d2.tar.gz kernel-qcow2-linux-ed7a01fd3fd77f40b4ef2562b966a5decd8928d2.tar.xz kernel-qcow2-linux-ed7a01fd3fd77f40b4ef2562b966a5decd8928d2.zip |
RDMA/restrack: Release task struct which was hold by CM_ID object
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>
Diffstat (limited to 'drivers/acpi/processor_driver.c')
0 files changed, 0 insertions, 0 deletions