All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Israel Rukshin <israelr@mellanox.com>
Cc: Max Gurtovoy <maxg@mellanox.com>,
	Sagi Grimberg <sagi@grimberg.me>,
	Linux-nvme <linux-nvme@lists.infradead.org>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 4/4] nvme: Fix controller use after free at create_ctrl callback
Date: Tue, 17 Mar 2020 13:56:33 +0100	[thread overview]
Message-ID: <20200317125633.GG12316@lst.de> (raw)
In-Reply-To: <e010bbdf-a28d-5ea5-2764-d624845bfe63@mellanox.com>

On Tue, Mar 17, 2020 at 01:49:43PM +0200, Israel Rukshin wrote:
>>
> Yes, for example you can see that nvme_rdma_create_ctrl() calls 
> nvme_rdma_setup_ctrl() which calls to nvme_start_ctrl().
>
> After calling nvme_rdma_setup_ctrl() we take the ref count on the ctrl by 
> calling nvme_get_ctrl().
>
> In case nvme_sysfs_delete() is called by the user before calling 
> nvme_get_ctrl() the controller ref count
>
> reach to zero and nvme_free_ctrl() is called.

> We can fix this by taking the ref count on earlier stage.

Why don't we do that?

> For example we can take a ref count at nvme_start_ctrl(), but it affects 
> also pci module (I need to check that),
>
> or we can take it before calling nvme_start_ctrl() at rdma/tcp. The ref 
> count should be taken only if  "new" is true.

I think we need the reference as soon as the controller is externally
visible in any way, which AFAICS is done by cdev_device_add in
nvme_init_ctrl.

_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

  reply	other threads:[~2020-03-17 12:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11 15:00 [PATCH 0/4] nvme: Fixes for deleting a ctrl before it was created Israel Rukshin
2020-03-11 15:00 ` [PATCH 1/4] nvme-rdma: Fix warning at nvme_rdma_setup_ctrl Israel Rukshin
2020-03-12  6:37   ` Sagi Grimberg
2020-03-12  9:03     ` Israel Rukshin
2020-03-12 23:08       ` Sagi Grimberg
2020-03-15  8:56         ` Israel Rukshin
2020-03-16 16:43           ` Sagi Grimberg
2020-03-16 18:43             ` Max Gurtovoy
2020-03-17 12:52   ` Christoph Hellwig
2020-03-11 15:00 ` [PATCH 2/4] nvme-tcp: Fix warning at nvme_tcp_setup_ctrl Israel Rukshin
2020-03-11 15:00 ` [PATCH 3/4] nvme: Remove unused return code from nvme_delete_ctrl_sync Israel Rukshin
2020-03-12  6:37   ` Sagi Grimberg
2020-03-17 12:53   ` Christoph Hellwig
2020-03-11 15:00 ` [PATCH 4/4] nvme: Fix controller use after free at create_ctrl callback Israel Rukshin
2020-03-12  6:45   ` Sagi Grimberg
2020-03-12 12:53     ` Israel Rukshin
2020-03-16 16:47       ` Sagi Grimberg
2020-03-17 11:49         ` Israel Rukshin
2020-03-17 12:56           ` Christoph Hellwig [this message]
2020-03-17 13:13             ` Israel Rukshin

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=20200317125633.GG12316@lst.de \
    --to=hch@lst.de \
    --cc=israelr@mellanox.com \
    --cc=linux-nvme@lists.infradead.org \
    --cc=maxg@mellanox.com \
    --cc=sagi@grimberg.me \
    /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.