linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Doug Ledford <dledford@redhat.com>,
	Avihai Horon <avihaih@nvidia.com>,
	linux-rdma@vger.kernel.org
Subject: Re: [PATCH rdma-next 4/4] RDMA/uverbs: Expose the new GID query API to user space
Date: Wed, 16 Sep 2020 13:37:10 +0300	[thread overview]
Message-ID: <20200916103710.GH486552@unreal> (raw)
In-Reply-To: <20200915190614.GE1573713@nvidia.com>

On Tue, Sep 15, 2020 at 04:06:14PM -0300, Jason Gunthorpe wrote:
> On Tue, Sep 15, 2020 at 02:47:04PM +0300, Leon Romanovsky wrote:
> > On Mon, Sep 14, 2020 at 12:55:50PM -0300, Jason Gunthorpe wrote:
> > > On Sun, Sep 13, 2020 at 12:13:02PM +0300, Leon Romanovsky wrote:
> > > > > > +static int UVERBS_HANDLER(UVERBS_METHOD_QUERY_GID_ENTRY)(
> > > > > > +	struct uverbs_attr_bundle *attrs)
> > > > > > +{
> > > > > > +	const struct ib_gid_attr *gid_attr;
> > > > > > +	struct ib_uverbs_gid_entry entry;
> > > > > > +	struct ib_ucontext *ucontext;
> > > > > > +	struct ib_device *ib_dev;
> > > > > > +	u32 gid_index;
> > > > > > +	u32 port_num;
> > > > > > +	u32 flags;
> > > > > > +	int ret;
> > > > > > +
> > > > > > +	ret = uverbs_get_flags32(&flags, attrs,
> > > > > > +				 UVERBS_ATTR_QUERY_GID_ENTRY_FLAGS, 0);
> > > > > > +	if (ret)
> > > > > > +		return ret;
> > > > > > +
> > > > > > +	ret = uverbs_get_const(&port_num, attrs,
> > > > > > +			       UVERBS_ATTR_QUERY_GID_ENTRY_PORT);
> > > > > > +	if (ret)
> > > > > > +		return ret;
> > > > > > +
> > > > > > +	ret = uverbs_get_const(&gid_index, attrs,
> > > > > > +			       UVERBS_ATTR_QUERY_GID_ENTRY_GID_INDEX);
> > > > > > +	if (ret)
> > > > > > +		return ret;
> > > > > > +
> > > > > > +	ucontext = ib_uverbs_get_ucontext(attrs);
> > > > > > +	if (IS_ERR(ucontext))
> > > > > > +		return PTR_ERR(ucontext);
> > > > > > +	ib_dev = ucontext->device;
> > > > >
> > > > > > +	if (!rdma_is_port_valid(ib_dev, port_num))
> > > > > > +		return -EINVAL;
> > > > > > +
> > > > > > +	if (!rdma_ib_or_roce(ib_dev, port_num))
> > > > > > +		return -EINVAL;
> > > > >
> > > > > Why these two tests? I would expect rdma_get_gid_attr() to do them
> > > >
> > > > First check is not needed, but the second check doesn't exist in
> > > > rdma_get_gid_attr(). We don't check that table returned from
> > > > rdma_gid_table() call exists.
> > >
> > > Oh that is a bit exciting, maybe it should be checked...
> > >
> > > Ideally we should also block this uapi entirely if the device doesn't
> > > have a gid table, so this should be -EOPNOTSUP and moved up to the
> > > top so it can be moved once we figure it out.
> >
> > It is already in earliest possible stage, right after we get ib_device.
>
> I usually put it before the uverbs_get_XX.. but doesn't matter
>
> > @@ -408,9 +409,17 @@ static int UVERBS_HANDLER(UVERBS_METHOD_QUERY_GID_ENTRY)(
> >  	entry.gid_index = gid_attr->index;
> >  	entry.port_num = gid_attr->port_num;
> >  	entry.gid_type = gid_attr->gid_type;
> > -	ret = rdma_get_ndev_ifindex(gid_attr, &entry.netdev_ifindex);
> > -	if (ret)
> > -		goto out;
> > +
> > +	if (rdma_protocol_roce(ib_dev, port_num)) {
>
> Not sure this is needed? non-roce still has gid table entries, and the
> attr->ndev should be null so it will do the ENODEV naturally.

It depends on how you want to treat errors from rdma_read_gid_attr_ndev_rcu().
Current check allows us to ensure that any error returned by this call is
handled.

Otherwise we will find ourselves with something like this:
ndev = rdma_read_gid_attr_ndev_rcu(gid_attr);
if (IS_ERR(ndev)) {
	if (rdma_protocol_roce())
		goto error;
	if (ERR_PTR(ndev) != -ENODEV)
	        goto error;
}

>
> > +		rcu_read_lock();
> > +		ndev = rdma_read_gid_attr_ndev_rcu(gid_attr);
> > +		if (IS_ERR(ndev)) {
> > +		       rcu_read_unlock();
> > +		       goto out;
> > +		}
> > +		entry.netdev_ifindex = ndev->ifindex;
> > +		rcu_read_unlock();
> > +	}
>
> This is better than what is in rdma_get_ndev_ifindex()
>
> Jason

  reply	other threads:[~2020-09-16 19:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-10 14:22 [PATCH rdma-next 0/4] Query GID table API Leon Romanovsky
2020-09-10 14:22 ` [PATCH rdma-next 1/4] RDMA/core: Change rdma_get_gid_attr returned error code Leon Romanovsky
2020-09-10 14:22 ` [PATCH rdma-next 2/4] RDMA/core: Modify enum ib_gid_type and enum rdma_network_type Leon Romanovsky
2020-09-11 19:11   ` Jason Gunthorpe
2020-09-13  7:42     ` Leon Romanovsky
2020-09-10 14:22 ` [PATCH rdma-next 3/4] RDMA/core: Introduce new GID table query API Leon Romanovsky
2020-09-11 19:52   ` Jason Gunthorpe
2020-09-13  8:02     ` Leon Romanovsky
2020-09-14 15:50       ` Jason Gunthorpe
2020-09-10 14:22 ` [PATCH rdma-next 4/4] RDMA/uverbs: Expose the new GID query API to user space Leon Romanovsky
2020-09-11 19:59   ` Jason Gunthorpe
2020-09-13  9:13     ` Leon Romanovsky
2020-09-14 15:55       ` Jason Gunthorpe
2020-09-15 11:47         ` Leon Romanovsky
2020-09-15 19:06           ` Jason Gunthorpe
2020-09-16 10:37             ` Leon Romanovsky [this message]
2020-09-16 12:04               ` Jason Gunthorpe
2020-09-16 12:44                 ` Leon Romanovsky
2020-09-16 14:12                   ` Jason Gunthorpe
2020-09-16 14:34                     ` Leon Romanovsky
2020-09-16 14:36                       ` 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=20200916103710.GH486552@unreal \
    --to=leon@kernel.org \
    --cc=avihaih@nvidia.com \
    --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).