From: Bjorn Helgaas <helgaas@kernel.org>
To: Dexuan Cui <decui@microsoft.com>
Cc: "lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Michael Kelley <mikelley@microsoft.com>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"driverdev-devel@linuxdriverproject.org"
<driverdev-devel@linuxdriverproject.org>,
Sasha Levin <Alexander.Levin@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
KY Srinivasan <kys@microsoft.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
"olaf@aepfle.de" <olaf@aepfle.de>,
"apw@canonical.com" <apw@canonical.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
vkuznets <vkuznets@redhat.com>,
"marcelo.cerri@canonical.com" <marcelo.cerri@canonical.com>,
"jackm@mellanox.com" <jackm@mellanox.com>
Subject: Re: [PATCH] PCI: hv: Fix panic by calling hv_pci_remove_slots() earlier
Date: Fri, 2 Aug 2019 14:40:53 -0500 [thread overview]
Message-ID: <20190802194053.GL151852@google.com> (raw)
In-Reply-To: <PU1P153MB0169DBCFEE7257F5BB93580ABFD90@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
Hi Dexuan,
The subject line only describes the mechanical code change, which is
obvious from the patch. It would be better if we could say something
about *why* we need this.
On Fri, Aug 02, 2019 at 01:32:28AM +0000, Dexuan Cui wrote:
>
> When a slot is removed, the pci_dev must still exist.
>
> pci_remove_root_bus() removes and free all the pci_devs, so
> hv_pci_remove_slots() must be called before pci_remove_root_bus(),
> otherwise a general protection fault can happen, if the kernel is built
"general protection fault" is an x86 term that doesn't really say what
the issue is. I suspect this would be a "use-after-free" problem.
> with the memory debugging options.
>
> Fixes: 15becc2b56c6 ("PCI: hv: Add hv_pci_remove_slots() when we unload the driver")
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> Cc: stable@vger.kernel.org
>
> ---
>
> When pci-hyperv is unloaded, this panic can happen:
>
> general protection fault:
> CPU: 2 PID: 1091 Comm: rmmod Not tainted 5.2.0+
> RIP: 0010:pci_slot_release+0x30/0xd0
> Call Trace:
> kobject_release+0x65/0x190
> pci_destroy_slot+0x25/0x60
> hv_pci_remove+0xec/0x110 [pci_hyperv]
> vmbus_remove+0x20/0x30 [hv_vmbus]
> device_release_driver_internal+0xd5/0x1b0
> driver_detach+0x44/0x7c
> bus_remove_driver+0x75/0xc7
> vmbus_driver_unregister+0x50/0xbd [hv_vmbus]
> __x64_sys_delete_module+0x136/0x200
> do_syscall_64+0x5e/0x220
>
> drivers/pci/controller/pci-hyperv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> index 6b9cc6e60a..68c611d 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -2757,8 +2757,8 @@ static int hv_pci_remove(struct hv_device *hdev)
> /* Remove the bus from PCI's point of view. */
> pci_lock_rescan_remove();
> pci_stop_root_bus(hbus->pci_bus);
> - pci_remove_root_bus(hbus->pci_bus);
> hv_pci_remove_slots(hbus);
> + pci_remove_root_bus(hbus->pci_bus);
I'm curious about why we need hv_pci_remove_slots() at all. None of
the other callers of pci_stop_root_bus() and pci_remove_root_bus() do
anything similar to hv_pci_remove_slots().
Surely some of those callers also support slots, so there must be some
other path that calls pci_destroy_slot() in those cases. Can we use a
similar strategy here?
> pci_unlock_rescan_remove();
> hbus->state = hv_pcibus_removed;
> }
> --
> 1.8.3.1
>
next prev parent reply other threads:[~2019-08-02 19:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-02 1:32 [PATCH] PCI: hv: Fix panic by calling hv_pci_remove_slots() earlier Dexuan Cui
[not found] ` <20190802180817.A206520578@mail.kernel.org>
2019-08-02 18:13 ` Dexuan Cui
2019-08-02 19:40 ` Bjorn Helgaas [this message]
2019-08-02 20:31 ` Dexuan Cui
2019-08-02 22:15 ` Bjorn Helgaas
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=20190802194053.GL151852@google.com \
--to=helgaas@kernel.org \
--cc=Alexander.Levin@microsoft.com \
--cc=apw@canonical.com \
--cc=decui@microsoft.com \
--cc=driverdev-devel@linuxdriverproject.org \
--cc=haiyangz@microsoft.com \
--cc=jackm@mellanox.com \
--cc=jasowang@redhat.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=marcelo.cerri@canonical.com \
--cc=mikelley@microsoft.com \
--cc=olaf@aepfle.de \
--cc=sthemmin@microsoft.com \
--cc=vkuznets@redhat.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.