All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Eric Davis" <eric.davis@broadcom.com>
Cc: linux-rdma@vger.kernel.org
Subject: Re: [PATCH rdma-next v3 11/13] RDMA/core: extended memory registration
Date: Tue, 10 Nov 2026 05:55:42 +0000	[thread overview]
Message-ID: <sashiko-outbox-206354@kernel.org> (raw)
In-Reply-To: <20261109-uet-ib-core-v3-11-3e7e7ffed2e9@broadcom.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] RDMA/core: incomplete MR field initialization in
  ib_mr_init_core_refs()
--

commit 4855334c45cbf4ca7471642a328bba73a433c013
Author: Eric Davis <eric.davis@broadcom.com>

RDMA/core: extended memory registration

This commit adds the reg_user_mr_ex device operation and extended UVERBS_METHOD_REG_MR ioctl attributes to support registering memory regions bound to a job, derived from a parent MR, or using caller-chosen 64-bit keys.

> diff --git a/drivers/infiniband/core/uverbs_std_types_mr.c b/drivers/infiniband/core/uverbs_std_types_mr.c
> index 0c72f801e0d32..8d281d13d2105 100644
> --- a/drivers/infiniband/core/uverbs_std_types_mr.c
> +++ b/drivers/infiniband/core/uverbs_std_types_mr.c
[ ... ]
> @@ -373,12 +521,26 @@ static int UVERBS_HANDLER(UVERBS_METHOD_REG_MR)(
>  	mr->device = pd->device;
>  	mr->pd = pd;
>  	mr->type = IB_MR_TYPE_USER;
> +	mr->iova = iova;
> +	mr->length = length;
> +	ib_mr_init_core_refs(mr);
>  	mr->uobject = uobj;
>  	atomic_inc(&pd->usecnt);
>  	if (dmah) {
>  		mr->dmah = dmah;
>  		atomic_inc(&dmah->usecnt);
>  	}
[ ... ]
> diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c
> index 9359318141b79..a80d750777f43 100644
> --- a/drivers/infiniband/core/verbs.c
> +++ b/drivers/infiniband/core/verbs.c
> @@ -2405,6 +2406,8 @@ int ib_dereg_mr_user(struct ib_mr *mr, struct ib_udata *udata)
>  	struct ib_pd *pd = mr->pd;
>  	struct ib_dm *dm = mr->dm;
>  	struct ib_dmah *dmah = mr->dmah;
> +	struct ib_jkey *jkey = mr->jkey;
> +	struct ib_mr *parent = mr->parent;
>  	struct ib_sig_attrs *sig_attrs = mr->sig_attrs;
>  	int ret;
>  
> @@ -2417,6 +2420,10 @@ int ib_dereg_mr_user(struct ib_mr *mr, struct ib_udata *udata)
>  			atomic_dec(&dm->usecnt);
>  		if (dmah)
>  			atomic_dec(&dmah->usecnt);
> +		if (jkey)
> +			atomic_dec(&jkey->usecnt);
> +		if (parent)
> +			atomic_dec(&parent->usecnt);
>  		kfree(sig_attrs);
>  	}
[ ... ]
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> index 8be766b80ce08..07fd5731d4587 100644
> --- a/include/rdma/ib_verbs.h
> +++ b/include/rdma/ib_verbs.h
[ ... ]
> @@ -4818,6 +4850,20 @@ static inline u32 ib_inc_rkey(u32 rkey)
>  	return ((rkey + 1) & mask) | (rkey & ~mask);
>  }
>  
> +/**
> + * ib_mr_init_core_refs - clears what core reads back when an MR is
> + *   deregistered.
> + * @mr: struct ib_mr pointer to initialize.
> + *
> + * A driver's MR need not be zeroed, so every path that makes an MR calls this.
> + */
> +static inline void ib_mr_init_core_refs(struct ib_mr *mr)
> +{
> +	mr->jkey = NULL;
> +	mr->parent = NULL;
> +	atomic_set(&mr->usecnt, 0);
> +}

[Severity: Medium]
Does ib_mr_init_core_refs() leave mr->dm, mr->dmah, and mr->sig_attrs
uninitialized when a driver returns a non-zeroed struct ib_mr?

The comment states that a driver's MR need not be zeroed and that
ib_mr_init_core_refs() clears what the core reads back on deregistration.
However, ib_dereg_mr_user() also reads mr->dm, mr->dmah, and mr->sig_attrs,
while UVERBS_HANDLER(UVERBS_METHOD_REG_MR),
UVERBS_HANDLER(UVERBS_METHOD_REG_DMABUF_MR), and ib_uverbs_rereg_mr() do not
clear them (and UVERBS_METHOD_REG_MR only sets mr->dmah when dmah is
non-NULL).  If a driver implementing reg_user_mr_ex or reg_user_mr does not
zero-initialize struct ib_mr, deregistering the MR will pass uninitialized
pointers to atomic_dec(&dm->usecnt), atomic_dec(&dmah->usecnt), and
kfree(sig_attrs), corrupting memory or crashing.

If ib_mr_init_core_refs() is updated to also clear mr->dm, mr->dmah, and
mr->sig_attrs, note that UVERBS_HANDLER(UVERBS_METHOD_DM_MR_REG) and
ib_alloc_mr_integrity() must call it before assigning mr->dm and
mr->sig_attrs.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109-uet-ib-core-v3-0-3e7e7ffed2e9@broadcom.com?part=11

  reply	other threads:[~2026-11-10  5:55 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10  4:00 [PATCH rdma-next v3 00/13] RDMA/core: Ultra Ethernet transport verbs Eric Davis
2026-11-10  4:00 ` Eric Davis via B4 Relay
2026-11-10  4:00 ` [PATCH rdma-next v3 01/13] RDMA/core: widen the uverbs object key Eric Davis
2026-11-10  4:00   ` Eric Davis via B4 Relay
2026-11-10  4:10   ` sashiko-bot
2026-11-10  4:00 ` [PATCH rdma-next v3 02/13] RDMA/core: add the UET GID types Eric Davis
2026-11-10  4:00   ` Eric Davis via B4 Relay
2026-11-10  4:21   ` sashiko-bot
2026-11-10  4:00 ` [PATCH rdma-next v3 03/13] RDMA/core: report the reliable unconnected device capabilities Eric Davis
2026-11-10  4:00   ` Eric Davis via B4 Relay
2026-11-10  4:25   ` sashiko-bot
2026-11-10  4:00 ` [PATCH rdma-next v3 04/13] RDMA/core: add the reliable unconnected queue pair type Eric Davis
2026-11-10  4:00   ` Eric Davis via B4 Relay
2026-11-10  4:36   ` sashiko-bot
2026-11-10  4:00 ` [PATCH rdma-next v3 05/13] RDMA/core: extended address handle attributes Eric Davis
2026-11-10  4:00   ` Eric Davis via B4 Relay
2026-11-10  4:45   ` sashiko-bot
2026-11-10  4:00 ` [PATCH rdma-next v3 06/13] RDMA/core: query the semantics a queue pair type guarantees Eric Davis
2026-11-10  4:00   ` Eric Davis via B4 Relay
2026-11-10  4:49   ` sashiko-bot
2026-11-10  4:00 ` [PATCH rdma-next v3 07/13] RDMA/core: job and job key objects Eric Davis
2026-11-10  4:00   ` Eric Davis via B4 Relay
2026-11-10  4:59   ` sashiko-bot
2026-11-10  4:00 ` [PATCH rdma-next v3 08/13] RDMA/uverbs: factor out the queue pair attribute copy Eric Davis
2026-11-10  4:00   ` Eric Davis via B4 Relay
2026-11-10  5:04   ` sashiko-bot
2026-11-10  4:00 ` [PATCH rdma-next v3 09/13] RDMA/core: create a queue pair ready to send Eric Davis
2026-11-10  4:00   ` Eric Davis via B4 Relay
2026-11-10  5:14   ` sashiko-bot
2026-11-10  4:00 ` [PATCH rdma-next v3 10/13] RDMA/core: queue pair attributes for unconnected transports Eric Davis
2026-11-10  4:00   ` Eric Davis via B4 Relay
2026-11-10  5:29   ` sashiko-bot
2026-11-11 16:45     ` Eric Davis
2026-11-10  4:00 ` [PATCH rdma-next v3 11/13] RDMA/core: extended memory registration Eric Davis
2026-11-10  4:00   ` Eric Davis via B4 Relay
2026-11-10  5:55   ` sashiko-bot [this message]
2026-11-11 16:46     ` Eric Davis
2026-11-10  4:00 ` [PATCH rdma-next v3 12/13] RDMA/core: 64-bit memory keys Eric Davis
2026-11-10  4:00   ` Eric Davis via B4 Relay
2026-11-10  6:01   ` sashiko-bot
2026-11-10  4:00 ` [PATCH rdma-next v3 13/13] RDMA/core: attach a memory region to a queue pair Eric Davis
2026-11-10  4:00   ` Eric Davis via B4 Relay
2026-11-10  6:20   ` sashiko-bot
2026-11-11 16:49     ` Eric Davis

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=sashiko-outbox-206354@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=eric.davis@broadcom.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.