From: Leon Romanovsky <leon@kernel.org>
To: Doug Ledford <dledford@redhat.com>, Jason Gunthorpe <jgg@nvidia.com>
Cc: Leon Romanovsky <leonro@nvidia.com>,
Adit Ranadive <aditr@vmware.com>,
Ariel Elior <aelior@marvell.com>,
Bernard Metzler <bmt@zurich.ibm.com>,
Christian Benvenuti <benve@cisco.com>,
Dennis Dalessandro <dennis.dalessandro@intel.com>,
Devesh Sharma <devesh.sharma@broadcom.com>,
Faisal Latif <faisal.latif@intel.com>,
Gal Pressman <galpress@amazon.com>,
Leon Romanovsky <leonro@mellanox.com>,
Lijun Ou <oulijun@huawei.com>,
linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
Michal Kalderon <mkalderon@marvell.com>,
Mike Marciniszyn <mike.marciniszyn@intel.com>,
Naresh Kumar PBS <nareshkumar.pbs@broadcom.com>,
Nelson Escobar <neescoba@cisco.com>,
Parvi Kaustubhi <pkaustub@cisco.com>,
Potnuri Bharat Teja <bharat@chelsio.com>,
Selvin Xavier <selvin.xavier@broadcom.com>,
Shiraz Saleem <shiraz.saleem@intel.com>,
Somnath Kotur <somnath.kotur@broadcom.com>,
Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>,
VMware PV-Drivers <pv-drivers@vmware.com>,
Weihang Li <liweihang@huawei.com>,
"Wei Hu(Xavier)" <huwei87@hisilicon.com>,
Yishai Hadas <yishaih@nvidia.com>,
Yuval Shaia <yuval.shaia@oracle.com>,
Zhu Yanjun <yanjunz@nvidia.com>
Subject: [PATCH rdma-next v2 0/9] Restore failure of destroy commands
Date: Mon, 7 Sep 2020 15:09:12 +0300 [thread overview]
Message-ID: <20200907120921.476363-1-leon@kernel.org> (raw)
From: Leon Romanovsky <leonro@nvidia.com>
Changelog:
v2:
* Rebased on top of the 524d8ffd07f0
* Removed "udata" check in destroy flows
* Changed ib_free_cq to return early
* Used Jason's suggestion to implement "RDMA/mlx5: Issue FW command to destroy
SRQ on reentry" patch.
v1
* Changed returned value in efa_destroy_ah() from EINVAL to EOPNOTSUPP
* https://lore.kernel.org/lkml/20200830084010.102381-1-leon@kernel.org
v0:
* https://lore.kernel.org/lkml/20200824103247.1088464-1-leon@kernel.org
-----------------------------------------------------------------------------
Hi,
This series restores the ability to fail on destroy commands, due to the
fact that mlx5_ib DEVX implementation interleaved ib_core objects
with FW objects without sharing reference counters.
In retrospect, every part of the mlx5_ib flow is correct.
It started from IBTA which was written by HW engineers with HW in mind and
they allowed to fail in destruction. FW implemented it with symmetrical
interface like any other command and propagated error back to the kernel,
which forwarded it to the libibverbs and kernel ULPs.
Libibverbs was designed with IBTA spec in hand putting destroy errors in
stone. Up till mlx5_ib DEVX, it worked well, because the IB verbs objects
are counted by the kernel and ib_core ensures that FW destroy will success
by managing various reference counters on such objects.
The extension of the mlx5 driver changed this flow when allowed DEVX objects
that are not managed by ib_core to be interleaved with the ones under ib_core
responsibility.
The drivers that want to implement DEVX flows must ensure that FW/HW
destroys are performed as early as possible before any other internal
cleanup. After HW destroys, drivers are not allowed to fail.
This series includes two patches (WQ and "potential race") that will
require extra work in mlx5_ib, they both theoretical. WQ is not in use
in DEVX, but is needed to make interface symmetrical to other objects.
"Potential race" is in ULP flow that ensures that SRQ is destroyed in
proper order.
Thanks
Leon Romanovsky (9):
RDMA: Restore ability to fail on PD deallocate
RDMA: Restore ability to fail on AH destroy
RDMA/mlx5: Issue FW command to destroy SRQ on reentry
RDMA: Restore ability to fail on SRQ destroy
RDMA/core: Delete function indirection for alloc/free kernel CQ
RDMA: Allow fail of destroy CQ
RDMA: Change XRCD destroy return value
RDMA: Restore ability to return error for destroy WQ
RDMA: Make counters destroy symmetrical
drivers/infiniband/core/cq.c | 30 ++---
drivers/infiniband/core/uverbs_std_types.c | 3 +-
.../core/uverbs_std_types_counters.c | 4 +-
drivers/infiniband/core/uverbs_std_types_wq.c | 2 +-
drivers/infiniband/core/verbs.c | 56 +++++++---
drivers/infiniband/hw/bnxt_re/ib_verbs.c | 12 +-
drivers/infiniband/hw/bnxt_re/ib_verbs.h | 8 +-
drivers/infiniband/hw/cxgb4/cq.c | 3 +-
drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 4 +-
drivers/infiniband/hw/cxgb4/provider.c | 3 +-
drivers/infiniband/hw/cxgb4/qp.c | 3 +-
drivers/infiniband/hw/efa/efa.h | 6 +-
drivers/infiniband/hw/efa/efa_verbs.c | 11 +-
drivers/infiniband/hw/hns/hns_roce_ah.c | 5 -
drivers/infiniband/hw/hns/hns_roce_cq.c | 3 +-
drivers/infiniband/hw/hns/hns_roce_device.h | 13 ++-
drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 3 +-
drivers/infiniband/hw/hns/hns_roce_pd.c | 3 +-
drivers/infiniband/hw/hns/hns_roce_srq.c | 3 +-
drivers/infiniband/hw/i40iw/i40iw_verbs.c | 6 +-
drivers/infiniband/hw/mlx4/ah.c | 5 -
drivers/infiniband/hw/mlx4/cq.c | 3 +-
drivers/infiniband/hw/mlx4/main.c | 6 +-
drivers/infiniband/hw/mlx4/mlx4_ib.h | 11 +-
drivers/infiniband/hw/mlx4/qp.c | 3 +-
drivers/infiniband/hw/mlx4/srq.c | 3 +-
drivers/infiniband/hw/mlx5/ah.c | 5 -
drivers/infiniband/hw/mlx5/cmd.c | 4 +-
drivers/infiniband/hw/mlx5/cmd.h | 2 +-
drivers/infiniband/hw/mlx5/counters.c | 3 +-
drivers/infiniband/hw/mlx5/cq.c | 16 ++-
drivers/infiniband/hw/mlx5/main.c | 4 +-
drivers/infiniband/hw/mlx5/mlx5_ib.h | 13 ++-
drivers/infiniband/hw/mlx5/qp.c | 12 +-
drivers/infiniband/hw/mlx5/qp.h | 4 +-
drivers/infiniband/hw/mlx5/qpc.c | 5 +-
drivers/infiniband/hw/mlx5/srq.c | 26 ++---
drivers/infiniband/hw/mlx5/srq.h | 2 +-
drivers/infiniband/hw/mlx5/srq_cmd.c | 22 +++-
drivers/infiniband/hw/mthca/mthca_provider.c | 12 +-
drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 3 +-
drivers/infiniband/hw/ocrdma/ocrdma_ah.h | 2 +-
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 11 +-
drivers/infiniband/hw/ocrdma/ocrdma_verbs.h | 6 +-
drivers/infiniband/hw/qedr/verbs.c | 14 ++-
drivers/infiniband/hw/qedr/verbs.h | 8 +-
drivers/infiniband/hw/usnic/usnic_ib_verbs.c | 7 +-
drivers/infiniband/hw/usnic/usnic_ib_verbs.h | 4 +-
drivers/infiniband/hw/vmw_pvrdma/pvrdma_cq.c | 3 +-
drivers/infiniband/hw/vmw_pvrdma/pvrdma_srq.c | 3 +-
.../infiniband/hw/vmw_pvrdma/pvrdma_verbs.c | 8 +-
.../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h | 8 +-
drivers/infiniband/sw/rdmavt/ah.c | 3 +-
drivers/infiniband/sw/rdmavt/ah.h | 2 +-
drivers/infiniband/sw/rdmavt/cq.c | 3 +-
drivers/infiniband/sw/rdmavt/cq.h | 2 +-
drivers/infiniband/sw/rdmavt/pd.c | 3 +-
drivers/infiniband/sw/rdmavt/pd.h | 2 +-
drivers/infiniband/sw/rdmavt/srq.c | 3 +-
drivers/infiniband/sw/rdmavt/srq.h | 2 +-
drivers/infiniband/sw/rxe/rxe_verbs.c | 12 +-
drivers/infiniband/sw/siw/siw_verbs.c | 9 +-
drivers/infiniband/sw/siw/siw_verbs.h | 6 +-
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 6 +-
include/rdma/ib_verbs.h | 105 +++++-------------
65 files changed, 308 insertions(+), 269 deletions(-)
--
2.26.2
next reply other threads:[~2020-09-07 17:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-07 12:09 Leon Romanovsky [this message]
2020-09-09 18:06 ` [PATCH rdma-next v2 0/9] Restore failure of destroy commands Jason Gunthorpe
2020-09-10 12:24 ` Leon Romanovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200907120921.476363-1-leon@kernel.org \
--to=leon@kernel.org \
--cc=aditr@vmware.com \
--cc=aelior@marvell.com \
--cc=benve@cisco.com \
--cc=bharat@chelsio.com \
--cc=bmt@zurich.ibm.com \
--cc=dennis.dalessandro@intel.com \
--cc=devesh.sharma@broadcom.com \
--cc=dledford@redhat.com \
--cc=faisal.latif@intel.com \
--cc=galpress@amazon.com \
--cc=huwei87@hisilicon.com \
--cc=jgg@nvidia.com \
--cc=leonro@mellanox.com \
--cc=leonro@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=liweihang@huawei.com \
--cc=mike.marciniszyn@intel.com \
--cc=mkalderon@marvell.com \
--cc=nareshkumar.pbs@broadcom.com \
--cc=neescoba@cisco.com \
--cc=oulijun@huawei.com \
--cc=pkaustub@cisco.com \
--cc=pv-drivers@vmware.com \
--cc=selvin.xavier@broadcom.com \
--cc=shiraz.saleem@intel.com \
--cc=somnath.kotur@broadcom.com \
--cc=sriharsha.basavapatna@broadcom.com \
--cc=yanjunz@nvidia.com \
--cc=yishaih@nvidia.com \
--cc=yuval.shaia@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox