From: Jason Gunthorpe <jgg@nvidia.com>
To: "Saleem, Shiraz" <shiraz.saleem@intel.com>
Cc: Gal Pressman <galpress@amazon.com>,
Leon Romanovsky <leon@kernel.org>,
Doug Ledford <dledford@redhat.com>,
Leon Romanovsky <leonro@mellanox.com>,
Adit Ranadive <aditr@vmware.com>,
Ariel Elior <aelior@marvell.com>,
"Bernard Metzler" <bmt@zurich.ibm.com>,
Christian Benvenuti <benve@cisco.com>,
"Dalessandro, Dennis" <dennis.dalessandro@intel.com>,
Devesh Sharma <devesh.sharma@broadcom.com>,
"Latif, Faisal" <faisal.latif@intel.com>,
"Lijun Ou" <oulijun@huawei.com>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
Michal Kalderon <mkalderon@marvell.com>,
"Marciniszyn, Mike" <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>,
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>,
Zhu Yanjun <yanjunz@nvidia.com>
Subject: Re: [PATCH rdma-next 01/10] RDMA: Restore ability to fail on PD deallocate
Date: Wed, 26 Aug 2020 08:40:43 -0300 [thread overview]
Message-ID: <20200826114043.GY1152540@nvidia.com> (raw)
In-Reply-To: <9DD61F30A802C4429A01CA4200E302A70106634FB5@fmsmsx124.amr.corp.intel.com>
On Wed, Aug 26, 2020 at 12:49:03AM +0000, Saleem, Shiraz wrote:
> The API is quite confusing now. If drivers are not expected to fail
> the destroy and there is no way to propagate the device failures,
> then the return type should be a void.
More or less, drivers can only return -EAGAIN with the idea that a
future call during the close process will eventually succeed.
Any permanent failure will trigger WARN_ON and a memory leak
Maybe we should switch the return code to bool or something to be a
little clearer that it is request to retry, not a failure?
Jason
next prev parent reply other threads:[~2020-08-26 11:41 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-24 10:32 [PATCH rdma-next 00/10] Restore failure of destroy commands Leon Romanovsky
2020-08-24 10:32 ` [PATCH rdma-next 01/10] RDMA: Restore ability to fail on PD deallocate Leon Romanovsky
2020-08-25 8:13 ` Gal Pressman
2020-08-25 8:38 ` Leon Romanovsky
2020-08-25 11:52 ` Jason Gunthorpe
2020-08-25 12:12 ` Gal Pressman
2020-08-25 12:34 ` Leon Romanovsky
2020-08-25 13:07 ` Jason Gunthorpe
2020-08-25 13:32 ` Gal Pressman
2020-08-25 13:44 ` Jason Gunthorpe
2020-08-25 13:50 ` Jason Gunthorpe
2020-08-25 14:04 ` Gal Pressman
2020-08-25 14:32 ` Jason Gunthorpe
2020-08-26 0:49 ` Saleem, Shiraz
2020-08-26 6:34 ` Leon Romanovsky
2020-08-26 11:40 ` Jason Gunthorpe [this message]
2020-08-27 2:06 ` Saleem, Shiraz
2020-08-27 6:56 ` Leon Romanovsky
2020-08-27 23:30 ` Saleem, Shiraz
2020-08-27 12:13 ` Jason Gunthorpe
2020-08-27 23:29 ` Saleem, Shiraz
2020-08-28 11:25 ` Jason Gunthorpe
2020-08-24 10:32 ` [PATCH rdma-next 02/10] RDMA: Restore ability to fail on AH destroy Leon Romanovsky
2020-08-25 8:13 ` Gal Pressman
2020-08-25 8:32 ` Leon Romanovsky
2020-08-24 10:32 ` [PATCH rdma-next 03/10] RDMA/mlx5: Issue FW command to destroy SRQ on reentry Leon Romanovsky
2020-08-24 10:32 ` [PATCH rdma-next 04/10] RDMA/mlx5: Fix potential race between destroy and CQE poll Leon Romanovsky
2020-08-24 10:32 ` [PATCH rdma-next 05/10] RDMA: Restore ability to fail on SRQ destroy Leon Romanovsky
2020-08-24 10:32 ` [PATCH rdma-next 06/10] RDMA/core: Delete function indirection for alloc/free kernel CQ Leon Romanovsky
2020-08-24 10:32 ` [PATCH rdma-next 07/10] RDMA: Allow fail of destroy CQ Leon Romanovsky
2020-08-24 10:32 ` [PATCH rdma-next 08/10] RDMA: Change XRCD destroy return value Leon Romanovsky
2020-08-24 10:32 ` [PATCH rdma-next 09/10] RDMA: Restore ability to return error for destroy WQ Leon Romanovsky
2020-08-24 10:32 ` [PATCH rdma-next 10/10] RDMA: Make counters destroy symmetrical 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=20200826114043.GY1152540@nvidia.com \
--to=jgg@nvidia.com \
--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=leon@kernel.org \
--cc=leonro@mellanox.com \
--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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.