All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@mellanox.com>
To: "Håkon Bugge" <haakon.bugge@oracle.com>
Cc: Doug Ledford <dledford@redhat.com>,
	OFED mailing list <linux-rdma@vger.kernel.org>,
	george kennedy <george.kennedy@oracle.com>
Subject: Re: [PATCH for-rc] RDMA/cma: fix race between addr_handler and resolve_route
Date: Tue, 14 Apr 2020 09:50:12 -0300	[thread overview]
Message-ID: <20200414125012.GK11945@mellanox.com> (raw)
In-Reply-To: <EAE5B24F-142B-478D-BBA5-BBF784AA9E39@oracle.com>

On Tue, Apr 14, 2020 at 12:34:35PM +0200, Håkon Bugge wrote:

> >>>> Shall I make a v2 base on next based on this idea, or do you have
> >>>> something coming?
> >>> 
> >>> Sure, I have nothing :)
> >>> 
> >>> Also that rdma_destroy_id in addr_handler looks wrong.. ie we still
> >>> retain pointers to the rdma_cm_id it destroys inside the struct
> >>> ucma_context, don't we?
> >> 
> >> On entry from user-space, we use the u32 id and looks it up in the
> >> XArray. But if rdma_destoy_id() is called asynchronously called
> >> between ucma_get_ctx_dev() and the de-reference of ctx->cm_id, we
> >> are toast.
> > 
> > Is that what happens on the addr_handler path?
> 
> No, there, the main problem is the revert of the state
> transitions. The first transition enables rdma_resolve_route() to
> pass its gate (i.e. state == ADDR_RESOLVED). Then it thinks the
> address is resolved, but the addr_handler changes its mind
> afterwards.

That is a problem, but the call to rdma_destroy_id looks like another
problem

Jason

  reply	other threads:[~2020-04-14 12:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-03 18:43 [PATCH for-rc] RDMA/cma: fix race between addr_handler and resolve_route Håkon Bugge
2020-04-03 18:57 ` Jason Gunthorpe
2020-04-03 19:07   ` Håkon Bugge
2020-04-03 19:36     ` Jason Gunthorpe
2020-04-06 17:00       ` Håkon Bugge
2020-04-06 17:31         ` Jason Gunthorpe
2020-04-06 18:02           ` Håkon Bugge
2020-04-06 18:10             ` Jason Gunthorpe
2020-04-14 10:34               ` Håkon Bugge
2020-04-14 12:50                 ` Jason Gunthorpe [this message]
2020-04-14 13:57                   ` Håkon Bugge
2020-04-14 16:11                     ` Jason Gunthorpe
2020-04-16 13:33                       ` Håkon Bugge
2020-04-16 18:55                         ` Jason Gunthorpe
2021-04-28  6:03   ` general protection fault in rdma_resolve_route syzbot

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=20200414125012.GK11945@mellanox.com \
    --to=jgg@mellanox.com \
    --cc=dledford@redhat.com \
    --cc=george.kennedy@oracle.com \
    --cc=haakon.bugge@oracle.com \
    --cc=linux-rdma@vger.kernel.org \
    /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.