All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Doug Ledford <dledford@redhat.com>, Jason Gunthorpe <jgg@mellanox.com>
Cc: Leon Romanovsky <leonro@mellanox.com>,
	RDMA mailing list <linux-rdma@vger.kernel.org>,
	Alex Vainman <alexv@mellanox.com>,
	Artemy Kovalyov <artemyko@mellanox.com>,
	Daniel Jurgens <danielj@mellanox.com>,
	Eli Cohen <eli@mellanox.com>, Haggai Eran <haggaie@mellanox.com>,
	Mark Zhang <markz@mellanox.com>, Moni Shoua <monis@mellanox.com>,
	Parav Pandit <parav@mellanox.com>,
	Sagi Grimberg <sagig@mellanox.com>,
	Yishai Hadas <yishaih@mellanox.com>
Subject: [PATCH rdma-rc 07/10] IB/mlx5: Prevent concurrent MR updates during invalidation
Date: Tue, 23 Jul 2019 09:57:30 +0300	[thread overview]
Message-ID: <20190723065733.4899-8-leon@kernel.org> (raw)
In-Reply-To: <20190723065733.4899-1-leon@kernel.org>

From: Moni Shoua <monis@mellanox.com>

Device requires that memory registration work requests that update the
address translation table of a MR will be fenced if posted together.
This scenario can happen when address ranges are invalidated by the
mmu in separate concurrent calls to the invalidation callback.

We prefer to block concurrent address updates for a single MR over
fencing since making the decision if a WQE needs fencing will be more
expensive and fencing all WQEs is a too radical choice.

Fixes: b4cfe447d47b ("IB/mlx5: Implement on demand paging by adding support for MMU notifiers")
Signed-off-by: Moni Shoua <monis@mellanox.com>
Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
 drivers/infiniband/hw/mlx5/odp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/mlx5/odp.c b/drivers/infiniband/hw/mlx5/odp.c
index 5b642d81e617..b54b851d54e8 100644
--- a/drivers/infiniband/hw/mlx5/odp.c
+++ b/drivers/infiniband/hw/mlx5/odp.c
@@ -246,7 +246,7 @@ void mlx5_ib_invalidate_range(struct ib_umem_odp *umem_odp, unsigned long start,
 	 * overwrite the same MTTs.  Concurent invalidations might race us,
 	 * but they will write 0s as well, so no difference in the end result.
 	 */
-
+	mutex_lock(&umem_odp->umem_mutex);
 	for (addr = start; addr < end; addr += BIT(umem_odp->page_shift)) {
 		idx = (addr - ib_umem_start(umem_odp)) >> umem_odp->page_shift;
 		/*
@@ -278,6 +278,7 @@ void mlx5_ib_invalidate_range(struct ib_umem_odp *umem_odp, unsigned long start,
 				   idx - blk_start_idx + 1, 0,
 				   MLX5_IB_UPD_XLT_ZAP |
 				   MLX5_IB_UPD_XLT_ATOMIC);
+	mutex_unlock(&umem_odp->umem_mutex);
 	/*
 	 * We are now sure that the device will not access the
 	 * memory. We can safely unmap it, and mark it as dirty if
--
2.20.1


  parent reply	other threads:[~2019-07-23  6:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-23  6:57 [PATCH rdma-rc 00/10] Collection of fixes for 5.3 Leon Romanovsky
2019-07-23  6:57 ` [PATCH rdma-rc 01/10] RDMA/core: Annotate destroy of mutex to ensure that it is released as unlocked Leon Romanovsky
2019-07-23  6:57 ` [PATCH rdma-rc 02/10] IB/mlx5: Fix unreg_umr to ignore the mkey state Leon Romanovsky
2019-07-23  6:57 ` [PATCH rdma-rc 03/10] IB/mlx5: Use direct mkey destroy command upon UMR unreg failure Leon Romanovsky
2019-07-23  6:57 ` [PATCH rdma-rc 04/10] IB/mlx5: Fix unreg_umr to set a device PD Leon Romanovsky
2019-07-23  6:57 ` [PATCH rdma-rc 05/10] IB/mlx5: Fix clean_mr() to work in the expected order Leon Romanovsky
2019-07-23  6:57 ` [PATCH rdma-rc 06/10] IB/mlx5: Fix RSS Toeplitz function to be specification aligned Leon Romanovsky
2019-07-23  6:57 ` Leon Romanovsky [this message]
2019-07-23  6:57 ` [PATCH rdma-rc 08/10] IB/mlx5: Avoid unnecessary typecast Leon Romanovsky
2019-07-23  6:57 ` [PATCH rdma-rc 09/10] IB/core: Fix querying total rdma stats Leon Romanovsky
2019-07-23  6:57 ` [PATCH rdma-rc 10/10] IB/counters: Initialize port counter and annotate mutex_destroy Leon Romanovsky
2019-07-25 14:32   ` Jason Gunthorpe
2019-07-25 15:13 ` [PATCH rdma-rc 00/10] Collection of fixes for 5.3 Jason Gunthorpe
2019-07-25 16:05   ` Parav Pandit

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=20190723065733.4899-8-leon@kernel.org \
    --to=leon@kernel.org \
    --cc=alexv@mellanox.com \
    --cc=artemyko@mellanox.com \
    --cc=danielj@mellanox.com \
    --cc=dledford@redhat.com \
    --cc=eli@mellanox.com \
    --cc=haggaie@mellanox.com \
    --cc=jgg@mellanox.com \
    --cc=leonro@mellanox.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=markz@mellanox.com \
    --cc=monis@mellanox.com \
    --cc=parav@mellanox.com \
    --cc=sagig@mellanox.com \
    --cc=yishaih@mellanox.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 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.