RDMA/mlx5: Fix a race with mlx5_ib_update_xlt on an implicit MR
authorJason Gunthorpe <jgg@mellanox.com>
Tue, 1 Oct 2019 15:38:17 +0000 (12:38 -0300)
committerJason Gunthorpe <jgg@mellanox.com>
Fri, 4 Oct 2019 18:54:21 +0000 (15:54 -0300)
commitf28b1932eaae183b80bd8c7abecae167a0e5c61a
tree51ff8d11eb0a15a3ee591c7d03a24e079fb71093
parent880505cfef1d086d18b59d2920eb2160429ffa1f
RDMA/mlx5: Fix a race with mlx5_ib_update_xlt on an implicit MR

mlx5_ib_update_xlt() must be protected against parallel free of the MR it
is accessing, also it must be called single threaded while updating the
HW. Otherwise we can have races of the form:

    CPU0                               CPU1
  mlx5_ib_update_xlt()
   mlx5_odp_populate_klm()
     odp_lookup() == NULL
     pklm = ZAP
                                      implicit_mr_get_data()
          implicit_mr_alloc()
    <update interval tree>
mlx5_ib_update_xlt
  mlx5_odp_populate_klm()
    odp_lookup() != NULL
    pklm = VALID
   mlx5_ib_post_send_wait()

    mlx5_ib_post_send_wait() // Replaces VALID with ZAP

This can be solved by putting both the SRCU and the umem_mutex lock around
every call to mlx5_ib_update_xlt(). This ensures that the content of the
interval tree relavent to mlx5_odp_populate_klm() (ie mr->parent == mr)
will not change while it is running, and thus the posted WRs to update the
KLM will always reflect the correct information.

The race above will resolve by either having CPU1 wait till CPU0 completes
the ZAP or CPU0 will run after the add and instead store VALID.

The pagefault path adding children already holds the umem_mutex and SRCU,
so the only missed lock is during MR destruction.

Fixes: 81713d3788d2 ("IB/mlx5: Add implicit MR support")
Link: https://lore.kernel.org/r/20191001153821.23621-3-jgg@ziepe.ca
Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
drivers/infiniband/hw/mlx5/odp.c