From: Leon Romanovsky <leon@kernel.org>
To: lirongqing <lirongqing@baidu.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>, Yishai Hadas <yishaih@nvidia.com>,
Edward Srouji <edwards@nvidia.com>,
Sean Hefty <sean.hefty@intel.com>,
Christian Koenig <christian.koenig@amd.com>,
"Michael J . Ruhl" <michael.j.ruhl@intel.com>,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] RDMA/uverbs: Set MR iova and length in ioctl reg paths
Date: Sun, 6 Sep 2026 12:06:16 +0300 [thread overview]
Message-ID: <20260906090616.GA56944@unreal> (raw)
In-Reply-To: <20260904022441.2200-1-lirongqing@baidu.com>
On Fri, Sep 04, 2026 at 10:24:41AM +0800, lirongqing wrote:
> From: Li RongQing <lirongqing@baidu.com>
>
> UVERBS_METHOD_REG_MR and UVERBS_METHOD_REG_DMABUF_MR do not
> initialize ib_mr->iova and ib_mr->length, unlike
> ib_uverbs_reg_mr() which assigns both from the command.
>
> Drivers that do not set these fields themselves are therefore left
> with zero values. UVERBS_METHOD_QUERY_MR and RDMA netlink then report
> zero iova and length. Some drivers also use these fields in their data
> path; for example, rxe uses them for range validation in
> mr_check_range(), causing accesses to MRs registered through these
> ioctl paths to fail.
>
> Drivers such as mlx5 that initialize the fields themselves are
> unaffected.
>
> Set iova and length in both ioctl handlers, matching the legacy
> registration path.
They are affected because you overwrite the fields set by an earlier
driver callback.
Thanks
>
> Fixes: 5b2e45049dc0 ("IB/core: Add UVERBS_METHOD_REG_MR on the MR object")
> Fixes: bfe0cc6eb249 ("RDMA/uverbs: Add uverbs command for dma-buf based MR registration")
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> drivers/infiniband/core/uverbs_std_types_mr.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/infiniband/core/uverbs_std_types_mr.c b/drivers/infiniband/core/uverbs_std_types_mr.c
> index 0c72f80..df02488 100644
> --- a/drivers/infiniband/core/uverbs_std_types_mr.c
> +++ b/drivers/infiniband/core/uverbs_std_types_mr.c
> @@ -247,6 +247,8 @@ static int UVERBS_HANDLER(UVERBS_METHOD_REG_DMABUF_MR)(
> mr->pd = pd;
> mr->type = IB_MR_TYPE_USER;
> mr->uobject = uobj;
> + mr->iova = iova;
> + mr->length = length;
> atomic_inc(&pd->usecnt);
>
> rdma_restrack_new(&mr->res, RDMA_RESTRACK_MR);
> @@ -374,6 +376,8 @@ static int UVERBS_HANDLER(UVERBS_METHOD_REG_MR)(
> mr->pd = pd;
> mr->type = IB_MR_TYPE_USER;
> mr->uobject = uobj;
> + mr->iova = iova;
> + mr->length = length;
> atomic_inc(&pd->usecnt);
> if (dmah) {
> mr->dmah = dmah;
> --
> 2.9.4
>
prev parent reply other threads:[~2026-09-06 9:06 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 2:24 lirongqing
2026-09-06 9:06 ` 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=20260906090616.GA56944@unreal \
--to=leon@kernel.org \
--cc=christian.koenig@amd.com \
--cc=edwards@nvidia.com \
--cc=jgg@ziepe.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=lirongqing@baidu.com \
--cc=michael.j.ruhl@intel.com \
--cc=sean.hefty@intel.com \
--cc=yishaih@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
all inboxes | Powered by JetHome®