From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Yinghai Lu <yinghai@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Bjorn Helgaas <bhelgaas@google.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Gu Zheng <guz.fnst@cn.fujitsu.com>,
Guo Chao <yan@linux.vnet.ibm.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Myron Stowe <myron.stowe@gmail.com>
Subject: Re: [PATCH v2 04/10] PCI: Destroy pci dev only once
Date: Sat, 7 Dec 2013 19:50:47 -0800 [thread overview]
Message-ID: <20131208035047.GB17629@kroah.com> (raw)
In-Reply-To: <CAE9FiQX0zvtfAW-0-aPjXyVuFzxg6PMtY9O_7csqEzyW2pr5Kw@mail.gmail.com>
On Sat, Dec 07, 2013 at 07:31:21PM -0800, Yinghai Lu wrote:
> [+ GregKH]
>
> On Fri, Dec 6, 2013 at 5:27 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Thursday, December 05, 2013 10:52:36 PM Yinghai Lu wrote:
> >> On Mon, Dec 2, 2013 at 6:49 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >> >
> >> > Scenario 5: pci_stop_and_remove_bus_device() is run concurrently
> >> > for a device and its parent bridge via remove_callback().
> >> >
> >> > In that case both code paths attempt to acquire
> >> > pci_remove_rescan_mutex. If the child device removal acquires
> >> > it first, there will be no problems. However, if the parent
> >> > bridge removal acquires it first, it will eventually execute
> >> > pci_destroy_dev() for the child device, but that device will
> >> > not be freed yet due to the reference held by the concurrent
> >> > child removal. Consequently, both pci_stop_bus_device() and
> >> > pci_remove_bus_device() will be executed for that device
> >> > unnecessarily and pci_destroy_dev() will see a corrupted list
> >> > head in that object. Moreover, an excess put_device() will
> >> > be executed for that device in that case which may lead to a
> >> > use-after-free in the final kobject_put() done by
> >> > sysfs_schedule_callback_work().
> >> >
> >> > Index: linux-pm/include/linux/pci.h
> >> > ===================================================================
> >> > --- linux-pm.orig/include/linux/pci.h
> >> > +++ linux-pm/include/linux/pci.h
> >> > @@ -321,6 +321,7 @@ struct pci_dev {
> >> > unsigned int multifunction:1;/* Part of multi-function device */
> >> > /* keep track of device state */
> >> > unsigned int is_added:1;
> >> > + unsigned int is_gone:1;
> >> > unsigned int is_busmaster:1; /* device is busmaster */
> >> > unsigned int no_msi:1; /* device may not use msi */
> >> > unsigned int block_cfg_access:1; /* config space access is blocked */
> >> > Index: linux-pm/drivers/pci/remove.c
> >> > ===================================================================
> >> > --- linux-pm.orig/drivers/pci/remove.c
> >> > +++ linux-pm/drivers/pci/remove.c
> >> > @@ -34,6 +34,7 @@ static void pci_stop_dev(struct pci_dev
> >> >
> >> > static void pci_destroy_dev(struct pci_dev *dev)
> >> > {
> >> > + dev->is_gone = 1;
> >> > device_del(&dev->dev);
> >> >
> >> > down_write(&pci_bus_sem);
> >> > @@ -109,8 +110,10 @@ static void pci_remove_bus_device(struct
> >> > */
> >> > void pci_stop_and_remove_bus_device(struct pci_dev *dev)
> >> > {
> >> > - pci_stop_bus_device(dev);
> >> > - pci_remove_bus_device(dev);
> >> > + if (!dev->is_gone) {
> >> > + pci_stop_bus_device(dev);
> >> > + pci_remove_bus_device(dev);
> >> > + }
> >> > }
> >> > EXPORT_SYMBOL(pci_stop_and_remove_bus_device);
> >> >
> >>
> >> Yes, above change should address sys double remove problem.
> >
> > I've just realized that we don't need a new flag for that, though.
> >
> > It looks like we only need to check dev->dev.kobj.parent and return if that is
> > NULL, because that means pci_destroy_dev() has run for that device already
> > (I'm wondering why device_del() doesn't clear dev->parent, BTW, it looks like
> > it should do that?).
> >
> > Of course, that still is going to be racy if we don't hold
> > pci_remove_rescan_mutex around pci_stop_and_remove_bus_device() in every code
> > path using it (or use another similar synchronization mechanism).
>
> Wonder if we can have safe way to check if device_del() is called already.
Nope.
> And those access_after_free should be addressed by driver core instead
> of pci code?
Nope, it's up to the bus to handle this. It shouldn't be hard, you
shouldn't actually care about this, if you do, something is wrong.
How is this PCI code so hard to get right? Look at USB for devices that
disappear from anywhere at anytime as an example for how to handle
this. PCI should be doing the same thing, no need for this "is_gone"
stuff.
greg k-h
next prev parent reply other threads:[~2013-12-08 3:49 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-26 1:28 [PATCH v2 00/10] PCI: Double removing fix and allocate 64bit mmio pref Yinghai Lu
2013-11-26 1:28 ` [PATCH v2 01/10] PCI: Use device_release_driver in pci_stop_root_bus Yinghai Lu
2013-11-27 1:09 ` Rafael J. Wysocki
2013-11-26 1:28 ` [PATCH v2 02/10] PCI: Move back pci_proc_attach_devices calling Yinghai Lu
2013-11-26 1:28 ` [PATCH v2 03/10] PCI: Move resources and bus_list releasing to pci_release_dev Yinghai Lu
2013-11-27 1:15 ` Rafael J. Wysocki
2013-11-27 2:15 ` Yinghai Lu
2013-11-26 1:28 ` [PATCH v2 04/10] PCI: Destroy pci dev only once Yinghai Lu
2013-11-26 3:38 ` Bjorn Helgaas
2013-11-26 19:34 ` Yinghai Lu
2013-11-26 20:13 ` Yinghai Lu
2013-11-27 1:24 ` Rafael J. Wysocki
2013-11-27 2:26 ` Yinghai Lu
2013-11-29 23:38 ` Rafael J. Wysocki
2013-11-29 23:45 ` Rafael J. Wysocki
2013-11-30 0:31 ` Rafael J. Wysocki
2013-11-30 21:37 ` Rafael J. Wysocki
2013-11-30 22:27 ` Yinghai Lu
2013-12-01 1:24 ` Rafael J. Wysocki
2013-12-02 1:29 ` Rafael J. Wysocki
2013-12-02 14:49 ` Rafael J. Wysocki
2013-12-05 22:40 ` Bjorn Helgaas
2013-12-06 1:21 ` Rafael J. Wysocki
2013-12-06 6:29 ` Yinghai Lu
2014-01-10 14:20 ` [PATCH 0/9] PCI: Eliminate race conditions between hotplug and sysfs rescan/remove (Was: Re: [PATCH v2 04/10] PCI: Destroy pci dev only once) Rafael J. Wysocki
2014-01-10 14:22 ` [PATCH 1/9] PCI: Global rescan-remove lock Rafael J. Wysocki
2014-01-10 14:23 ` [PATCH 2/9] ACPI / PCI: Use global PCI rescan-remove locking in PCI root hotplug Rafael J. Wysocki
2014-01-10 14:24 ` [PATCH 3/9] ACPI / hotplug / PCI: Use global PCI rescan-remove locking Rafael J. Wysocki
2014-01-10 14:25 ` [PATCH 4/9] PCMCIA / cardbus: " Rafael J. Wysocki
2014-01-10 14:26 ` [PATCH 5/9] PCI / hotplug: " Rafael J. Wysocki
2014-01-10 14:27 ` [PATCH 6/9] platform / x86: " Rafael J. Wysocki
2014-01-10 14:27 ` [PATCH 7/9] MPT / PCI: Use pci_stop_and_remove_bus_device_locked() Rafael J. Wysocki
2014-01-10 14:28 ` [PATCH 8/9] powerpc / eeh_driver: Use global PCI rescan-remove locking Rafael J. Wysocki
2014-01-15 13:36 ` [Update][PATCH " Rafael J. Wysocki
2014-01-15 17:38 ` Bjorn Helgaas
2014-01-10 14:29 ` [PATCH 9/9] Xen / PCI: " Rafael J. Wysocki
2014-01-15 18:02 ` [PATCH 0/9] PCI: Eliminate race conditions between hotplug and sysfs rescan/remove (Was: Re: [PATCH v2 04/10] PCI: Destroy pci dev only once) Bjorn Helgaas
2013-12-06 6:52 ` [PATCH v2 04/10] PCI: Destroy pci dev only once Yinghai Lu
2013-12-07 1:27 ` Rafael J. Wysocki
2013-12-08 3:31 ` Yinghai Lu
2013-12-08 3:50 ` Greg Kroah-Hartman [this message]
2013-12-09 15:24 ` Ethan Zhao
2013-12-09 19:08 ` Greg Kroah-Hartman
2013-12-10 7:43 ` Ethan Zhao
2014-01-13 1:03 ` [PATCH] PCI / remove: Check parent kobject in pci_destroy_dev() (was: Re: [PATCH v2 04/10] PCI: Destroy pci dev only once) Rafael J. Wysocki
2013-11-27 1:17 ` [PATCH v2 04/10] PCI: Destroy pci dev only once Rafael J. Wysocki
2013-11-26 1:28 ` [PATCH v2 05/10] PCI: pcibus address to resource converting take bus directly Yinghai Lu
2013-11-26 1:28 ` [PATCH v2 06/10] PCI: Add pcibios_bus_addr_to_res() Yinghai Lu
2013-11-26 1:28 ` [PATCH v2 07/10] PCI: Try to allocate mem64 above 4G at first Yinghai Lu
2013-11-26 4:15 ` Bjorn Helgaas
2013-11-26 20:14 ` Yinghai Lu
2013-11-26 1:28 ` [PATCH v2 08/10] PCI: Try best to allocate pref mmio 64bit above 4g Yinghai Lu
2013-11-26 4:17 ` Bjorn Helgaas
2013-11-26 6:59 ` Guo Chao
2013-11-26 17:53 ` Bjorn Helgaas
2013-11-26 22:00 ` Yinghai Lu
2013-11-26 22:01 ` Bjorn Helgaas
2013-11-27 0:33 ` Yinghai Lu
2013-11-26 1:28 ` [PATCH v2 09/10] PCI: Sort pci root bus resources list Yinghai Lu
2013-11-26 4:18 ` Bjorn Helgaas
2013-11-26 1:28 ` [PATCH v2 10/10] intel-gtt: Read 64bit for gmar_bus_addr Yinghai Lu
2013-11-26 3:46 ` Bjorn Helgaas
2013-11-26 19:35 ` Yinghai Lu
2013-12-11 18:48 ` Bjorn Helgaas
2013-12-11 19:58 ` Yinghai Lu
2013-12-21 0:27 ` Bjorn Helgaas
2013-12-21 1:19 ` Yinghai Lu
2013-12-21 18:50 ` Bjorn Helgaas
2013-12-23 22:33 ` 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=20131208035047.GB17629@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=bhelgaas@google.com \
--cc=guz.fnst@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=myron.stowe@gmail.com \
--cc=rafael.j.wysocki@intel.com \
--cc=rjw@rjwysocki.net \
--cc=yan@linux.vnet.ibm.com \
--cc=yinghai@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox