From: Leon Romanovsky <leon@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Doug Ledford <dledford@redhat.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 16:05:57 +0300 [thread overview]
Message-ID: <20201002130557.GE3094@unreal> (raw)
In-Reply-To: <20201002125535.GA1344115@nvidia.com>
On Fri, Oct 02, 2020 at 09:55:35AM -0300, Jason Gunthorpe wrote:
> 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?
Both NULL and RDMA_RESTRACK_CM_ID are not needed, this is how I
discovered the need to clean the cma.c, but left it here.
Thanks
>
> Jason
prev parent reply other threads:[~2020-10-02 13:06 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
2020-10-02 13:05 ` Leon Romanovsky [this message]
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=20201002130557.GE3094@unreal \
--to=leon@kernel.org \
--cc=dledford@redhat.com \
--cc=jgg@nvidia.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).