a27a377ac4
The call to update_ibv_state could result in a segfault if the other thread had already freed the qp and was just spinning on handling the rdma event. By not updating the qpair state here, I don't think that we lose any information about the qpair state. Especiallyy since just a little bit later we update the qpair state to be in error. There is nothing in the man pages about the cm events changing the ib state although I imagine they are closely related. I just say that because I believe that's why the update was originally in that spot. fixes: GitHub issue #1110 Change-Id: I3f87ff009bc2019464ed7c6920dd71e2b286b3fd Signed-off-by: Seth Howell <seth.howell@intel.com> Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/477877 Community-CI: Broadcom SPDK FC-NVMe CI <spdk-ci.pdl@broadcom.com> Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Alexey Marchuk <alexeymar@mellanox.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> |
||
---|---|---|
.. | ||
ctrlr_bdev.c | ||
ctrlr_discovery.c | ||
ctrlr.c | ||
fc_ls.c | ||
fc.c | ||
Makefile | ||
nvmf_fc.h | ||
nvmf_internal.h | ||
nvmf_rpc.c | ||
nvmf.c | ||
rdma.c | ||
subsystem.c | ||
tcp.c | ||
transport.c | ||
transport.h |