From: Leon Romanovsky <leon@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Avihai Horon <avihaih@nvidia.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
linux-rdma@vger.kernel.org, Meir Lichtinger <meirl@mellanox.com>,
Michael Guralnik <michaelgur@mellanox.com>,
netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
Saeed Mahameed <saeedm@nvidia.com>, Shay Drory <shayd@nvidia.com>
Subject: [PATCH rdma-next 2/4] RDMA/mlx5: Check pcie_relaxed_ordering_enabled() in UMR
Date: Mon, 10 Apr 2023 16:07:51 +0300 [thread overview]
Message-ID: <8d39eb8317e7bed1a354311a20ae707788fd94ed.1681131553.git.leon@kernel.org> (raw)
In-Reply-To: <cover.1681131553.git.leon@kernel.org>
From: Avihai Horon <avihaih@nvidia.com>
relaxed_ordering_read HCA capability is set if both the device supports
relaxed ordering (RO) read and RO is set in PCI config space.
RO in PCI config space can change during runtime. This will change the
value of relaxed_ordering_read HCA capability in FW, but the driver will
not see it since it queries the capabilities only once.
This can lead to the following scenario:
1. RO in PCI config space is enabled.
2. User creates MKey without RO.
3. RO in PCI config space is disabled.
As a result, relaxed_ordering_read HCA capability is turned off in FW
but remains on in driver copy of the capabilities.
4. User requests to reconfig the MKey with RO via UMR.
5. Driver will try to reconfig the MKey with RO read although it
shouldn't (as relaxed_ordering_read HCA capability is really off).
To fix this, check pcie_relaxed_ordering_enabled() before setting RO
read in UMR.
Fixes: 896ec9735336 ("RDMA/mlx5: Set mkey relaxed ordering by UMR with ConnectX-7")
Signed-off-by: Avihai Horon <avihaih@nvidia.com>
Reviewed-by: Shay Drory <shayd@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
drivers/infiniband/hw/mlx5/umr.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/umr.c b/drivers/infiniband/hw/mlx5/umr.c
index 55f4e048d947..c9e176e8ced4 100644
--- a/drivers/infiniband/hw/mlx5/umr.c
+++ b/drivers/infiniband/hw/mlx5/umr.c
@@ -380,6 +380,9 @@ static void mlx5r_umr_set_access_flags(struct mlx5_ib_dev *dev,
struct mlx5_mkey_seg *seg,
unsigned int access_flags)
{
+ bool ro_read = (access_flags & IB_ACCESS_RELAXED_ORDERING) &&
+ pcie_relaxed_ordering_enabled(dev->mdev->pdev);
+
MLX5_SET(mkc, seg, a, !!(access_flags & IB_ACCESS_REMOTE_ATOMIC));
MLX5_SET(mkc, seg, rw, !!(access_flags & IB_ACCESS_REMOTE_WRITE));
MLX5_SET(mkc, seg, rr, !!(access_flags & IB_ACCESS_REMOTE_READ));
@@ -387,8 +390,7 @@ static void mlx5r_umr_set_access_flags(struct mlx5_ib_dev *dev,
MLX5_SET(mkc, seg, lr, 1);
MLX5_SET(mkc, seg, relaxed_ordering_write,
!!(access_flags & IB_ACCESS_RELAXED_ORDERING));
- MLX5_SET(mkc, seg, relaxed_ordering_read,
- !!(access_flags & IB_ACCESS_RELAXED_ORDERING));
+ MLX5_SET(mkc, seg, relaxed_ordering_read, ro_read);
}
int mlx5r_umr_rereg_pd_access(struct mlx5_ib_mr *mr, struct ib_pd *pd,
--
2.39.2
next prev parent reply other threads:[~2023-04-10 13:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-10 13:07 [PATCH rdma-next 0/4] Allow relaxed ordering read in VFs and VMs Leon Romanovsky
2023-04-10 13:07 ` [PATCH mlx5-next 1/4] RDMA/mlx5: Remove pcie_relaxed_ordering_enabled() check for RO write Leon Romanovsky
2023-04-11 23:18 ` Jacob Keller
2023-04-10 13:07 ` Leon Romanovsky [this message]
2023-04-11 23:18 ` [PATCH rdma-next 2/4] RDMA/mlx5: Check pcie_relaxed_ordering_enabled() in UMR Jacob Keller
2023-04-10 13:07 ` [PATCH mlx5-next 3/4] net/mlx5: Update relaxed ordering read HCA capabilities Leon Romanovsky
2023-04-11 23:19 ` Jacob Keller
2023-04-10 13:07 ` [PATCH mlx5-next 4/4] RDMA/mlx5: Allow relaxed ordering read in VFs and VMs Leon Romanovsky
2023-04-11 23:19 ` Jacob Keller
2023-04-11 14:01 ` [PATCH rdma-next 0/4] " Jason Gunthorpe
2023-04-11 14:09 ` Leon Romanovsky
2023-04-11 23:21 ` Jacob Keller
2023-04-13 12:49 ` Leon Romanovsky
2023-04-13 14:46 ` Jason Gunthorpe
2023-04-16 10:28 ` Leon Romanovsky
2023-04-16 10:30 ` Leon Romanovsky
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=8d39eb8317e7bed1a354311a20ae707788fd94ed.1681131553.git.leon@kernel.org \
--to=leon@kernel.org \
--cc=avihaih@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jgg@nvidia.com \
--cc=kuba@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=meirl@mellanox.com \
--cc=michaelgur@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=shayd@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