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>
Subject: Re: [PATCH rdma-next v3 9/9] RDMA/restrack: Drop valid restrack field as source of ambiguity
Date: Fri, 2 Oct 2020 09:55:35 -0300	[thread overview]
Message-ID: <20201002125535.GA1344115@nvidia.com> (raw)
In-Reply-To: <20200926101938.2964394-10-leon@kernel.org>

On Sat, Sep 26, 2020 at 01:19:38PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
> 
> The valid field was needed to distinguish between supported/not
> supported QPs, after the create_qp was changed to support all types,
> that field can be dropped in a favor of no_track field.
> 
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
>  drivers/infiniband/core/restrack.c | 29 ++++++++---------------------
>  include/rdma/restrack.h            |  9 ---------
>  2 files changed, 8 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/infiniband/core/restrack.c b/drivers/infiniband/core/restrack.c
> index 593af32d86a0..6ca3e6f3adb5 100644
> +++ b/drivers/infiniband/core/restrack.c
> @@ -143,7 +143,7 @@ static struct ib_device *res_to_dev(struct rdma_restrack_entry *res)
>  		return container_of(res, struct rdma_counter, res)->device;
>  	default:
>  		WARN_ONCE(true, "Wrong resource tracking type %u\n", res->type);
> -		return NULL;
> +		return ERR_PTR(-EINVAL);
>  	}
>  }
>  
> @@ -223,7 +223,7 @@ int __must_check rdma_restrack_add(struct rdma_restrack_entry *res)
>  	struct rdma_restrack_root *rt;
>  	int ret = 0;
>  
> -	if (!dev)
> +	if (IS_ERR_OR_NULL(dev))
>  		return -ENODEV;

dev can't be NULL

Not sure why this was changed? The error code is always thrown away,
what was wrong with keeping it as NULL? 

Now that all callers check the return code this should be a WARN_ON as
calling restrack_add in a way that is guarenteed to fail us a ULP
error.

> +	WARN_ONCE(!dev && res->type != RDMA_RESTRACK_CM_ID,
> +		  "IB device should be set for restrack type %s",
> +		  type2str(res->type));
> +	if (res->no_track || IS_ERR_OR_NULL(dev))
>  		goto out;

dev is never NULL so that WARN_ONCE doesn't work

Why does this exclude CM_ID? I thought all the fixing in the cm was so
restrack_add and _del were prefectly paired and a device must be
present?

Jason

  reply	other threads:[~2020-10-02 12:55 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
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 [this message]
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=20201002125535.GA1344115@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=dledford@redhat.com \
    --cc=leon@kernel.org \
    --cc=leonro@mellanox.com \
    --cc=linux-rdma@vger.kernel.org \
    /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).