All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: lirongqing <lirongqing@baidu.com>
Cc: linux-rdma@vger.kernel.org
Subject: Re: [PATCH v2] RDMA/mlx5: Wait for in-flight page faults on implicit MR null_mkey dereg
Date: Thu, 24 Sep 2026 07:04:19 +0000	[thread overview]
Message-ID: <20260924070420.88FB41F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260924065017.2424-1-lirongqing@baidu.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] RDMA/mlx5: child MR leak in mlx5_ib_free_odp_mr due to late null_mmkey wait
--

commit f5fc9e80765babb54d4d8c2db70efadd75e2ccc8
Author: Li RongQing <lirongqing@baidu.com>

    RDMA/mlx5: Wait for in-flight page faults on implicit MR null_mkey dereg

This commit mirrors the main-mmkey handling for null_mmkey by dropping the
reference and waiting for any in-flight faults to finish before destroying
the mkey and freeing the imr. It also initializes the waitqueue for the
null_mmkey right after creation to avoid a NULL pointer dereference.

> diff --git a/drivers/infiniband/hw/mlx5/odp.c b/drivers/infiniband/hw/mlx5/odp.c
> index 8dcbb0e5ccd7c..c7367718e24f2 100644
> --- a/drivers/infiniband/hw/mlx5/odp.c
> +++ b/drivers/infiniband/hw/mlx5/odp.c
[ ... ]
> @@ -683,6 +684,8 @@ void mlx5_ib_free_odp_mr(struct mlx5_ib_mr *mr)
>  		xa_erase(&mr_to_mdev(mr)->odp_mkeys,
>  			 mlx5_base_mkey(mr->null_mmkey.key));
>  
> +		mlx5r_deref_wait_odp_mkey(&mr->null_mmkey);
> +

[Severity: High]
Does this code leak child MRs when an in-flight page fault races with MR
deregistration?

If a page fault on an implicit ODP MR uses the null_mmkey and is queued
concurrently with MR deregistration, __mlx5_ib_dereg_mr() will call
mlx5_ib_free_odp_mr() which iterates over and deletes existing child MRs.

Because the null_mmkey is erased and waited upon here, after the
mr->implicit_children xarray is already cleaned up, the in-flight page
fault handler can still look up the null_mmkey, take a reference, and
create a new child MR.

The new child is inserted into mr->implicit_children (which succeeds
because the slot was just emptied by the cleanup loop). Finally,
mlx5_ib_free_odp_mr() waits for the handlers to finish. The parent mr is
freed, but the newly created child MR is permanently leaked and retains a
dangling parent pointer.

>  		mlx5_core_destroy_mkey(mr_to_mdev(mr)->mdev,
>  				       mr->null_mmkey.key);
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260924065017.2424-1-lirongqing@baidu.com?part=1

      reply	other threads:[~2026-09-24  7:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24  6:50 [PATCH v2] RDMA/mlx5: Wait for in-flight page faults on implicit MR null_mkey dereg lirongqing
2026-09-24  7:04 ` sashiko-bot [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=20260924070420.88FB41F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=lirongqing@baidu.com \
    --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.