All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai.lu@oracle.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/8] pci: Make sriov work with hotplug removal
Date: Tue, 18 Oct 2011 10:02:18 -0700	[thread overview]
Message-ID: <4E9DB11A.7030505@oracle.com> (raw)
In-Reply-To: <CAErSpo4PLDfapndXJp-sXS-SJtv0a7PaD=UKX0HV0OV34an3kQ@mail.gmail.com>

On 10/18/2011 09:49 AM, Bjorn Helgaas wrote:
> On Mon, Oct 17, 2011 at 4:24 PM, Yinghai Lu<yinghai.lu@oracle.com>  wrote:
>> On 10/17/2011 03:12 PM, Bjorn Helgaas wrote:
>>>
>>> Maybe this is the best we can do, but it still doesn't seem ideal, and
>>> it's certainly not obvious when reading the code.  It doesn't seem
>>> right for the driver ->remove() method to be calling
>>> pci_destroy_dev().   Won't the core data structures be corrupted if a
>>> defective driver doesn't call pci_disable_sriov()?  Seems like we
>>> could end up with a device that's been physically removed, but still
>>> has pci_dev structs hanging around.
>>
>> i did add some print out in
>>         pci_stop_bus_device
>> when stop PF, that function is called for those VFs.
>>
>> also driver have to call pci_disable_sriov() and that is current design.
>
> Yep.  But I don't have to like the current design :)  It doesn't seem
> as robust as it could be.
>
> It took me a long time to puzzle out what was happening here.  Here's
> some possible changelog text that would have saved me a lot of time:
>
>      The PCI hot-remove path calls pci_stop_bus_devices() via
>      pci_remove_bus_device().
>
>      pci_stop_bus_devices() traverses the bus->devices list (point A below),
>      stopping each device in turn, which calls the driver remove() method.  When
>      the device is an SR-IOV PF, the driver calls pci_disable_sriov(), which
>      also uses pci_remove_bus_device() to remove the VF devices from the
>      bus->devices list (point B).
>
>          pci_remove_bus_device
>            pci_stop_bus_device
>              pci_stop_bus_devices(subordinate)
>                list_for_each(bus->devices)<-- A
>                  pci_stop_bus_device(PF)
>                    ...
>                      driver->remove
>                        pci_disable_sriov
>                          ...
>                            pci_remove_bus_device(VF)
>                                <remove from bus_list>   <-- B
>
>      At B, we're changing the same list we're iterating through at A, so when
>      the driver remove() method returns, the pci_stop_bus_devices() iterator has
>      a pointer to a list entry that has already been freed.
>
>      This patch avoids the problem by building a separate list of all PFs on
>      the bus and traversing that at A instead of the bus->devices list.

yes.

  reply	other threads:[~2011-10-18 17:00 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4E9A3092.4080309@oracle.com>
2011-10-16  1:31 ` [PATCH 1/8] pci: Make sriov work with hotplug removal Yinghai Lu
2011-10-17 17:16   ` Bjorn Helgaas
2011-10-17 18:08     ` Yinghai Lu
2011-10-17 22:12       ` Bjorn Helgaas
2011-10-17 22:24         ` Yinghai Lu
2011-10-18 16:49           ` Bjorn Helgaas
2011-10-18 17:02             ` Yinghai Lu [this message]
2011-10-25 12:34               ` Kenji Kaneshige
2011-10-25 15:52                 ` Yinghai Lu
2011-11-11 21:00               ` [RESEND PATCH] PCI: Make sriov work with hotplug remove Yinghai Lu
2011-11-16  5:54                 ` Kenji Kaneshige
2011-11-16 21:23                   ` Yinghai Lu
2011-11-23  1:58                     ` Kenji Kaneshige
2011-11-23  5:01                       ` [PATCH -v4] " Yinghai Lu
2011-10-16  1:31 ` [PATCH 2/8] pci: Calculate right add_size Yinghai Lu
2011-10-16  1:32 ` [PATCH 3/8] pci: Try to assign required+option size at first Yinghai Lu
2011-10-16  1:32 ` [PATCH 4/8] PCI: Using add_list in pcie hotplug path Yinghai Lu
2011-10-16  1:32 ` [PATCH 5/8] PCI: Make rescan bus could increase bridge resource size if needed Yinghai Lu
2011-10-16  1:32 ` [PATCH 6/8] PCI: Make pci_rescan_bus handle add_list Yinghai Lu
2011-10-16  1:32 ` [PATCH 7/8] PCI, sysfs: merge dev and bus cpuaffinity show handling Yinghai Lu
2011-10-16  1:32 ` [PATCH 8/8] PCI, sys: only create rescan under /sys/.../pci/devices/... for pci bridges Yinghai Lu
2011-10-16  2:39   ` Greg KH
2011-10-16  5:34     ` Yinghai Lu
2011-10-16 15:55       ` Greg KH
2011-10-16 23:35         ` Yinghai Lu
2011-10-17  1:45           ` Greg KH
2011-10-17 18:27             ` [PATCH -v4 8_1/8] PCI, sys: Use device_type and attr_groups with pci dev Yinghai Lu
2011-10-17 18:38               ` Greg KH
2011-10-17 18:29             ` [PATCH -v4 8_2/8] PCI, sys: only create rescan under /sys/.../pci/devices/... for pci bridges Yinghai Lu
2011-10-17 18:33             ` [PATCH -v4 8_3/8] PCI, sys: Use is_visable() with boot_vga attribute for pci_dev Yinghai Lu
2011-10-17 18:36             ` [PATCH 8/8] PCI, sys: only create rescan under /sys/.../pci/devices/... for pci bridges Yinghai Lu

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=4E9DB11A.7030505@oracle.com \
    --to=yinghai.lu@oracle.com \
    --cc=bhelgaas@google.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@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.