summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/processor_driver.c
diff options
context:
space:
mode:
authorLeon Romanovsky2018-10-02 10:48:03 +0200
committerJason Gunthorpe2018-10-06 00:07:39 +0200
commited7a01fd3fd77f40b4ef2562b966a5decd8928d2 (patch)
treef8d97bcf113c3b66db0d88632334cfc55d7ef9f4 /drivers/acpi/processor_driver.c
parentRDMA/restrack: Consolidate task name updates in one place (diff)
downloadkernel-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