linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Doug Ledford <dledford@redhat.com>,
	Leon Romanovsky <leonro@mellanox.com>,
	<linux-rdma@vger.kernel.org>, Mark Zhang <markz@nvidia.com>
Subject: Re: [PATCH rdma-next v3 6/9] RDMA/restrack: Add error handling while adding restrack object
Date: Fri, 2 Oct 2020 10:13:18 -0300	[thread overview]
Message-ID: <20201002131318.GA1344650@nvidia.com> (raw)
In-Reply-To: <20200926101938.2964394-7-leon@kernel.org>

On Sat, Sep 26, 2020 at 01:19:35PM +0300, Leon Romanovsky wrote:
> @@ -449,7 +453,10 @@ static int ib_uverbs_alloc_pd(struct uverbs_attr_bundle *attrs)
>  	ret = ib_dev->ops.alloc_pd(pd, &attrs->driver_udata);
>  	if (ret)
>  		goto err_alloc;
> -	rdma_restrack_add(&pd->res);
> +
> +	ret = rdma_restrack_add(&pd->res);
> +	if (ret)
> +		goto err_restrack;
>  
>  	uobj->object = pd;
>  	uobj_finalize_uobj_create(uobj, attrs);
> @@ -457,6 +464,9 @@ static int ib_uverbs_alloc_pd(struct uverbs_attr_bundle *attrs)
>  	resp.pd_handle = uobj->id;
>  	return uverbs_response(attrs, &resp, sizeof(resp));
>  
> +err_restrack:
> +	ib_dev->ops.dealloc_pd(pd, &attrs->driver_udata);

There can be no failure between allocating the HW object and calling
uobj_finalize_uobj_create(). That was the whole point of that scheme.
It is really important that be kept.

Now that destroys are allowed to fail we aboslutely cannot have any
open coded destroys like this *anywhere* in the uobject system.

I think you need to go back to a model where the xarray allocation can
fail but we can still call del, otherwise the error unwind is a
complete nightmare.

This also has problems like this:

int ib_dereg_mr_user(struct ib_mr *mr, struct ib_udata *udata)
{
	rdma_restrack_del(&mr->res);
	ret = mr->device->ops.dereg_mr(mr, udata);
	if (!ret) {

With the uobject destroy retry scheme restrack_del will be called
multiple times.

I think this is pretty simple to solve, write del as this:

void rdma_restrack_del(struct rdma_restrack_entry *res)
{
	struct ib_device *dev = res_to_dev(res);
	struct rdma_restrack_entry *old;
	struct rdma_restrack_root *rt;

	if (WARN_ON(!dev))
		return

	rt = &dev->res[res->type];
	if (xa_cmpxchg(&rt->xa, res->id, res, NULL, GFP_KERNEL) != res)
		return;
	rdma_restrack_put(res);
	wait_for_completion(&res->comp);
}

There is no need to do the wait_for_completion if we didn't change the
xarray.

Jason

  parent reply	other threads:[~2020-10-02 13:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-26 10:19 [PATCH rdma-next v3 0/9] Track memory allocation with restrack DB help Leon Romanovsky
2020-09-26 10:19 ` [PATCH rdma-next v3 1/9] RDMA/core: Allow drivers to disable restrack DB Leon Romanovsky
2020-09-26 10:19 ` [PATCH rdma-next v3 2/9] RDMA/counter: Combine allocation and bind logic Leon Romanovsky
2020-09-26 10:19 ` [PATCH rdma-next v3 3/9] RDMA/restrack: Store all special QPs in restrack DB Leon Romanovsky
2020-09-26 10:19 ` [PATCH rdma-next v3 4/9] RDMA/cma: Add missing error handling of listen_id Leon Romanovsky
2020-09-26 10:19 ` [PATCH rdma-next v3 5/9] RDMA/cma: Be strict with attaching to CMA device Leon Romanovsky
2020-09-26 10:19 ` [PATCH rdma-next v3 6/9] RDMA/restrack: Add error handling while adding restrack object Leon Romanovsky
2020-10-02 12:42   ` Jason Gunthorpe
2020-10-02 12:57     ` Leon Romanovsky
2020-10-02 13:16       ` Jason Gunthorpe
2020-10-04  6:48         ` Leon Romanovsky
2020-10-04 12:32           ` Jason Gunthorpe
2020-10-04 12:49             ` Leon Romanovsky
2020-10-04 13:03               ` Jason Gunthorpe
2020-10-02 13:13   ` Jason Gunthorpe [this message]
2020-10-04  6:04     ` Leon Romanovsky
2020-09-26 10:19 ` [PATCH rdma-next v3 7/9] RDMA/restrack: Support all QP types Leon Romanovsky
2020-09-26 10:19 ` [PATCH rdma-next v3 8/9] RDMA/core: Track device memory MRs Leon Romanovsky
2020-09-26 10:19 ` [PATCH rdma-next v3 9/9] RDMA/restrack: Drop valid restrack field as source of ambiguity Leon Romanovsky
2020-10-02 12:55   ` Jason Gunthorpe
2020-10-02 13:05     ` 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=20201002131318.GA1344650@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=dledford@redhat.com \
    --cc=leon@kernel.org \
    --cc=leonro@mellanox.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=markz@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).