All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Michael Gur" <michaelgur@nvidia.com>, linux-rdma@vger.kernel.org
Subject: Re: [PATCH rdma-next v2 14/15] RDMA/mlx5: Support new Unordered access flag
Date: Tue, 03 Nov 2026 22:35:04 +0000	[thread overview]
Message-ID: <sashiko-outbox-196139@kernel.org> (raw)
In-Reply-To: <20261102223325.2115128-15-michaelgur@nvidia.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] RDMA/mlx5: missing IB_ACCESS_UNORDERED in _mlx5r_umr_update_mr_pas() for DD
--

commit d54e400e3350128fbcd9fb5d5bce4f37dfe241bd
Author: Michael Gur <michaelgur@nvidia.com>

RDMA/mlx5: Support new Unordered access flag

This commit adds mlx5_ib support for the IB_ACCESS_UNORDERED flag by mapping
it to MLX5_MKEY_ORDER_UNORDERED, enabling ATS on DMABUF MRs with unordered
access, and marking the flag as unchangeable via UMR.

> diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> index dd1fe8fd42206..75ea3f91e9314 100644
> --- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
> +++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> @@ -1672,11 +1672,13 @@ static inline bool mlx5_umem_needs_ats(struct mlx5_ib_dev *dev,
>  {
>  	if (!MLX5_CAP_GEN(dev->mdev, ats) || !umem->is_dmabuf)
>  		return false;
> -	return access_flags & IB_ACCESS_RELAXED_ORDERING;
> +	return access_flags & (IB_ACCESS_RELAXED_ORDERING | IB_ACCESS_UNORDERED);
>  }
>  
>  static inline enum mlx5_mkey_order mlx5r_access_to_mkey_order(int access_flags)
>  {
> +	if (access_flags & IB_ACCESS_UNORDERED)
> +		return MLX5_MKEY_ORDER_UNORDERED;
>  	if (access_flags & IB_ACCESS_RELAXED_ORDERING)
>  		return MLX5_MKEY_ORDER_RELAXED;
>  	return MLX5_MKEY_ORDER_STRICT;

[Severity: Medium]
As reported by Sashiko on v1 [1], when a Data-Direct DMABUF MR is registered
with IB_ACCESS_UNORDERED via mlx5_ib_reg_user_mr_dmabuf() ->
reg_user_mr_dmabuf_by_data_direct(), both crossed_mr and crossing_mr are
configured with MLX5_MKEY_ORDER_UNORDERED and ATS via
mlx5r_access_to_mkey_order() and mlx5_umem_needs_ats().

However, when populating the KSM entries in
drivers/infiniband/hw/mlx5/umr.c:_mlx5r_umr_update_mr_pas(), only
IB_ACCESS_RELAXED_ORDERING is checked when selecting between mdd->mkey_ro and
mdd->mkey:

		if (dd) {
			struct mlx5_data_direct *mdd = dev->mdev->data_direct;

			cur_ksm->va = cpu_to_be64(rdma_block_iter_dma_address(&biter));
			if (mr->access_flags & IB_ACCESS_RELAXED_ORDERING &&
			    mdd->mkey_ro_valid)
				cur_ksm->key = cpu_to_be32(mdd->mkey_ro);
			else
				cur_ksm->key = cpu_to_be32(mdd->mkey);

Similarly, in
drivers/infiniband/hw/mlx5/mr.c:reg_user_mr_dmabuf_by_data_direct(), when
mkey_ro_valid is false, only IB_ACCESS_RELAXED_ORDERING is masked out of
access_flags:

	if (!dev->mdev->data_direct->mkey_ro_valid)
		access_flags &= ~IB_ACCESS_RELAXED_ORDERING;

Should _mlx5r_umr_update_mr_pas() and reg_user_mr_dmabuf_by_data_direct()
also handle IB_ACCESS_UNORDERED so that Data-Direct KSM entries and
crossed_mr/crossing_mr ordering match the underlying Data-Direct mkey?

[1] https://lore.kernel.org/r/20260726092943.2880176-15-michaelgur@nvidia.com

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102223325.2115128-1-michaelgur@nvidia.com?part=14

  reply	other threads:[~2026-11-03 22:35 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-02 22:32 [PATCH rdma-next v2 00/15] RDMA: Support HW requiring relaxed ordering and add Unordered access flag Michael Gur
2026-11-02 22:32 ` [PATCH rdma-next v2 01/15] RDMA/mlx5: Allow optional access flags in DM registration Michael Gur
2026-11-03 22:34   ` sashiko-bot
2026-11-02 22:32 ` [PATCH rdma-next v2 02/15] RDMA/mlx5: Allow optional access flags in DEVX UMEM registration Michael Gur
2026-11-03 22:34   ` sashiko-bot
2026-11-02 22:32 ` [PATCH rdma-next v2 03/15] RDMA/core: Allow optional access flags in dmabuf reg ioctl Michael Gur
2026-11-03 22:34   ` sashiko-bot
2026-11-02 22:32 ` [PATCH rdma-next v2 04/15] RDMA/core: Allow optional access flags in reg mr ioctl Michael Gur
2026-11-03 22:34   ` sashiko-bot
2026-11-02 22:32 ` [PATCH rdma-next v2 05/15] mlx5: Rename IFC bits of relaxed ordering fields Michael Gur
2026-11-03 22:34   ` sashiko-bot
2026-11-02 22:32 ` [PATCH rdma-next v2 06/15] net/mlx5: Add IFC bits for new ordering caps Michael Gur
2026-11-03 22:34   ` sashiko-bot
2026-11-02 22:33 ` [PATCH rdma-next v2 07/15] mlx5: Consolidate mkey ordering setting into a single core helper Michael Gur
2026-11-03 22:34   ` sashiko-bot
2026-11-02 22:33 ` [PATCH rdma-next v2 08/15] net/mlx5: Enable relaxed ordering on resource dump mkey Michael Gur
2026-11-03 22:35   ` sashiko-bot
2026-11-02 22:33 ` [PATCH rdma-next v2 09/15] net/mlx5: Enable relaxed ordering on FW tracer mkey Michael Gur
2026-11-03 22:35   ` sashiko-bot
2026-11-02 22:33 ` [PATCH rdma-next v2 10/15] vfio/mlx5: Enable relaxed ordering on the live migration data mkey Michael Gur
2026-11-03 22:35   ` sashiko-bot
2026-11-02 22:33 ` [PATCH rdma-next v2 11/15] RDMA/mlx5: Enable relaxed ordering on ODP null mkey Michael Gur
2026-11-03 22:35   ` sashiko-bot
2026-11-02 22:33 ` [PATCH rdma-next v2 12/15] RDMA/mlx5: Converge UMR access-flag cap checks Michael Gur
2026-11-03 22:35   ` sashiko-bot
2026-11-02 22:33 ` [PATCH rdma-next v2 13/15] RDMA/uverbs: Add new Unordered MR access flag Michael Gur
2026-11-03 22:35   ` sashiko-bot
2026-11-02 22:33 ` [PATCH rdma-next v2 14/15] RDMA/mlx5: Support new Unordered " Michael Gur
2026-11-03 22:35   ` sashiko-bot [this message]
2026-11-05 14:50     ` Michael Gur
2026-11-02 22:33 ` [PATCH rdma-next v2 15/15] RDMA/mlx5: Enforce relaxed ordering when HW requires it Michael Gur
2026-11-03 22:35   ` sashiko-bot
2026-11-05 15:00     ` Michael Gur

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-196139@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=michaelgur@nvidia.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.