From: Gal Pressman <galpress@amazon.com>
To: Jason Gunthorpe <jgg@ziepe.ca>,
Selvin Xavier <selvin.xavier@broadcom.com>
Cc: Leon Romanovsky <leon@kernel.org>,
Doug Ledford <dledford@redhat.com>, <linux-rdma@vger.kernel.org>
Subject: Re: [PATCH for-rc 1/6] RDMA/bnxt_re: Remove the qp from list only if the qp destroy succeeds
Date: Tue, 25 Aug 2020 14:44:41 +0300 [thread overview]
Message-ID: <8f629ba0-4862-70a4-f2e3-6721653a4955@amazon.com> (raw)
In-Reply-To: <20200824220002.GF24045@ziepe.ca>
On 25/08/2020 1:00, Jason Gunthorpe wrote:
> On Tue, Aug 25, 2020 at 01:06:23AM +0530, Selvin Xavier wrote:
>> On Tue, Aug 25, 2020 at 12:31 AM Leon Romanovsky <leon@kernel.org> wrote:
>>>
>>> On Mon, Aug 24, 2020 at 11:14:31AM -0700, Selvin Xavier wrote:
>>>> Driver crashes when destroy_qp is re-tried because of an
>>>> error returned. This is because the qp entry was removed
>>>> from the qp list during the first call.
>>>
>>> How is it possible that destroy_qp fail?
>>>
>> One possibility is when the FW is in a crash state. Driver commands
>> to FW fails and it reports an error status for destroy_qp verb.
>> Even Though the chances of this failure is less, wanted to avoid a
>> host crash seen in this scenario.
>
> Drivers are not allowed to fail destroy - the only exception is if a
> future destroy would succeed for some reason.
Why?
We already have the iterative cleanup in uverbs_destroy_ufile_hw, and combined
with Leon's changes it makes sense that the actual return value is returned
instead of ignored.
If the subsystem handles it for DEVX, why shouldn't it handle it for other drivers?
next prev parent reply other threads:[~2020-08-25 11:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-24 18:14 [PATCH for-rc 0/6] RDMA/bnxt_re: Bug fixes Selvin Xavier
2020-08-24 18:14 ` [PATCH for-rc 1/6] RDMA/bnxt_re: Remove the qp from list only if the qp destroy succeeds Selvin Xavier
2020-08-24 19:01 ` Leon Romanovsky
2020-08-24 19:36 ` Selvin Xavier
2020-08-24 22:00 ` Jason Gunthorpe
2020-08-25 11:44 ` Gal Pressman [this message]
2020-08-24 18:14 ` [PATCH for-rc 2/6] RDMA/bnxt_re: Do not report transparent vlan from QP1 Selvin Xavier
2020-08-24 18:14 ` [PATCH for-rc 3/6] RDMA/bnxt_re: Fix the qp table indexing Selvin Xavier
2020-08-24 18:14 ` [PATCH for-rc 4/6] RDMA/bnxt_re: Static NQ depth allocation Selvin Xavier
2020-08-24 18:14 ` [PATCH for-rc 5/6] RDMA/bnxt_re: Restrict the max_gids to 256 Selvin Xavier
2020-08-24 18:14 ` [PATCH for-rc 6/6] RDMA/bnxt_re: Fix driver crash on unaligned PSN entry address Selvin Xavier
2020-08-27 12:31 ` [PATCH for-rc 0/6] RDMA/bnxt_re: Bug fixes Jason Gunthorpe
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=8f629ba0-4862-70a4-f2e3-6721653a4955@amazon.com \
--to=galpress@amazon.com \
--cc=dledford@redhat.com \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=selvin.xavier@broadcom.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.