From: Jason Gunthorpe <jgg@nvidia.com>
To: Hillf Danton <hdanton@sina.com>, <linux-rdma@vger.kernel.org>
Cc: Sean Hefty <sean.hefty@intel.com>,
<syzbot+cc6fc752b3819e082d0c@syzkaller.appspotmail.com>
Subject: Re: [PATCH] RDMA/ucma: Rework ucma_migrate_id() to avoid races with destroy
Date: Fri, 18 Sep 2020 20:54:36 -0300 [thread overview]
Message-ID: <20200918235436.GA453065@nvidia.com> (raw)
In-Reply-To: <0-v1-05c5a4090305+3a872-ucma_syz_migrate_jgg@nvidia.com>
On Mon, Sep 14, 2020 at 08:59:56AM -0300, Jason Gunthorpe wrote:
> ucma_destroy_id() assumes that all things accessing the ctx will do so via
> the xarray. This assumption violated only in the case the FD is being
> closed, then the ctx is reached via the ctx_list. Normally this is OK
> since ucma_destroy_id() cannot run concurrenty with release(), however
> with ucma_migrate_id() is involved this can violated as the close of the
> 2nd FD can run concurrently with destroy on the first:
>
> CPU0 CPU1
> ucma_destroy_id(fda)
> ucma_migrate_id(fda -> fdb)
> ucma_get_ctx()
> xa_lock()
> _ucma_find_context()
> xa_erase()
> xa_unlock()
> xa_lock()
> ctx->file = new_file
> list_move()
> xa_unlock()
> ucma_put_ctx()
>
> ucma_close(fdb)
> _destroy_id()
> kfree(ctx)
>
> _destroy_id()
> wait_for_completion()
> // boom, ctx was freed
>
> The ctx->file must be modified under the handler and xa_lock, and prior to
> modification the ID must be rechecked that it is still reachable from
> cur_file, ie there is no parallel destroy or migrate.
>
> To make this work remove the double locking and streamline the control
> flow. The double locking was obsoleted by the handler lock now directly
> preventing new uevents from being created, and the ctx_list cannot be read
> while holding fgets on both files. Removing the double locking also
> removes the need to check for the same file.
>
> Fixes: 88314e4dda1e ("RDMA/cma: add support for rdma_migrate_id()")
> Reported-and-tested-by: syzbot+cc6fc752b3819e082d0c@syzkaller.appspotmail.com
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/infiniband/core/ucma.c | 79 +++++++++++++---------------------
> 1 file changed, 29 insertions(+), 50 deletions(-)
Applied to for-next
Jason
prev parent reply other threads:[~2020-09-18 23:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-14 11:59 [PATCH] RDMA/ucma: Rework ucma_migrate_id() to avoid races with destroy Jason Gunthorpe
2020-09-18 23:54 ` Jason Gunthorpe [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=20200918235436.GA453065@nvidia.com \
--to=jgg@nvidia.com \
--cc=hdanton@sina.com \
--cc=linux-rdma@vger.kernel.org \
--cc=sean.hefty@intel.com \
--cc=syzbot+cc6fc752b3819e082d0c@syzkaller.appspotmail.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.