From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58164) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUg8A-00008S-SB for qemu-devel@nongnu.org; Wed, 16 May 2012 11:27:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUg85-00067u-Lq for qemu-devel@nongnu.org; Wed, 16 May 2012 11:27:14 -0400 Received: from mail-lpp01m010-f45.google.com ([209.85.215.45]:61895) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUg85-00066i-6y for qemu-devel@nongnu.org; Wed, 16 May 2012 11:27:09 -0400 Received: by lahc1 with SMTP id c1so735084lah.4 for ; Wed, 16 May 2012 08:27:06 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4FAD1B88.2060905@gmail.com> References: <1315976141-6684-1-git-send-email-akong@redhat.com> <20120510154423.11306.85353.stgit@t> <4FABF639.4070205@gmail.com> <20120510185516.GI14647@redhat.com> <4FAC5518.5060807@redhat.com> <4FAC5C32.9080009@redhat.com> <4FAD1B88.2060905@gmail.com> From: Bjorn Helgaas Date: Wed, 16 May 2012 09:26:45 -0600 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3] pci: clean all funcs when hot-removing multifunc device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jiang Liu Cc: "Michael S. Tsirkin" , linux-pci@vger.kernel.org, seabios@seabios.org, qemu-devel@nongnu.org, jbarnes@virtuousgeek.org, alex.williamson@redhat.com, kevin@koconnor.net, Kenji Kaneshige , Amos Kong , Yinghai Lu On Fri, May 11, 2012 at 8:00 AM, Jiang Liu wrote: > On 05/11/2012 08:24 AM, Amos Kong wrote: >> On 05/11/2012 07:54 AM, Amos Kong wrote: >>> On 05/11/2012 02:55 AM, Michael S. Tsirkin wrote: >>>> On Fri, May 11, 2012 at 01:09:13AM +0800, Jiang Liu wrote: >>>>> On 05/10/2012 11:44 PM, Amos Kong wrote: >>>>> >>>>>> diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplu= g/acpiphp_glue.c >>>>>> index 806c44f..a7442d9 100644 >>>>>> --- a/drivers/pci/hotplug/acpiphp_glue.c >>>>>> +++ b/drivers/pci/hotplug/acpiphp_glue.c >>>>>> @@ -885,7 +885,7 @@ static void disable_bridges(struct pci_bus *bus) >>>>>> =A0static int disable_device(struct acpiphp_slot *slot) >>>>>> =A0{ >>>>>> =A0 struct acpiphp_func *func; >>>>>> - struct pci_dev *pdev; >>>>>> + struct pci_dev *pdev, *tmp; >>>>>> =A0 struct pci_bus *bus =3D slot->bridge->pci_bus; >>>>>> >>>>>> =A0 /* The slot will be enabled when func 0 is added, so check >>>>>> @@ -902,9 +902,10 @@ static int disable_device(struct acpiphp_slot *= slot) >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 func->bridge =3D NULL; >>>>>> =A0 =A0 =A0 =A0 =A0 } >>>>>> >>>>>> - =A0 =A0 =A0 =A0 pdev =3D pci_get_slot(slot->bridge->pci_bus, >>>>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PCI_DEVFN(= slot->device, func->function)); >>>>>> - =A0 =A0 =A0 =A0 if (pdev) { >>>>>> + =A0 =A0 =A0 =A0 list_for_each_entry_safe(pdev, tmp, &bus->devices,= bus_list) { >>>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (PCI_SLOT(pdev->devfn) !=3D slo= t->device) >>>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue; I think the concept is good: in enable_device(), we use pci_scan_slot(), which scans all possible functions in the slot. So in disable_device() we should do something symmetric to remove all the functions. >>>>>> + >>>>> The pci_bus_sem lock should be acquired when walking the bus->devices= list. >>>>> Otherwise it may cause invalid memory access if another thread is mod= ifying >>>>> the bus->devices list concurrently. >> >> pci_bus_sem lock is only request for writing &bus->devices list, right ? >> and this protection already exists in pci_destory_dev(). > That's for writer. For reader to walk the pci_bus->devices list, you also= need > to acquire the reader lock by down_read(&pci_bus_sem). Please refer to > pci_get_slot() for example. This especially import for native OS because = there > may be multiple PCI slots/devices on the bus. There is a lot of existing code that walks bus->devices without holding pci_bus_sem, but most of it is boot-time code that is arguably safe (though I think things like pcibios_fixup_bus() are poorly designed and don't fit well in the hotplug-enabled world). In this case, I do think we need to protect against updates while we're walking bus->devices. It's probably not trivial because __pci_remove_bus_device() calls pci_destroy_dev(), where we do the down_write(), so simply wrapping the whole thing with down_read() will cause a deadlock. Kenji-san, Yinghai, do you have any input? Bjorn