linux-kernel - Re: [PATCH v6 04/30] xen/PCI: Don't use deprecated function pci_scan_bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55024D35.6050509@huawei.com>
Date:	Fri, 13 Mar 2015 10:36:37 +0800
From:	Yijing Wang <wangyijing@...wei.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
CC:	Jiang Liu <jiang.liu@...ux.intel.com>, <linux-pci@...r.kernel.org>,
	Yinghai Lu <yinghai@...nel.org>,
	<linux-kernel@...r.kernel.org>,
	Marc Zyngier <marc.zyngier@....com>,
	<linux-arm-kernel@...ts.infradead.org>,
	Russell King <linux@....linux.org.uk>, <x86@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Tony Luck <tony.luck@...el.com>, <linux-ia64@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	"Guan Xuetao" <gxt@...c.pku.edu.cn>, <linux-alpha@...r.kernel.org>,
	<linux-m68k@...ts.linux-m68k.org>, Liviu Dudau <liviu@...au.co.uk>,
	"Arnd Bergmann" <arnd@...db.de>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>,
	<xen-devel@...ts.xenproject.org>
Subject: Re: [PATCH v6 04/30] xen/PCI: Don't use deprecated function pci_scan_bus_parented()

>>>> +	pci_add_resource(&resources, &ioport_resource);
>>>> +	pci_add_resource(&resources, &iomem_resource);
>>>> +	pci_add_resource(&resources, &busn_resource);
>>>
>>> Since I don't want to export busn_resource, you might have to allocate your
>>> own struct resource for it here.  And, of course, figure out the details of
>>> which PCI domain you're in and whether you need to share one struct
>>> resource across several host bridges in the same domain.
>>
>> Allocate its own resource here is ok for me, as I mentioned in previous reply,
>> so do we still need to add additional info to figure out which domain own the bus resource ?
> 
> That's up to the caller.  Only the platform knows which bridges it wants to
> have in the same domain.  In principle, every host bridge could be in its
> own domain, since each bridge is the root of a unique PCI hierarchy.  But
> some platforms have firmware that assumes otherwise.  I have no idea what
> xen assumes.

I'm not xen guy, so I don't know much about it, but because it call pci_scan_bus_parented()
before, and in which busn_resource is always shared for different host bridges(same domain or not),
I think add a static bus resource(0,255) should be safe, at least, it would not introduce new risk.

Something like:

diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index b1ffebe..a69e529 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -446,9 +446,15 @@ static int pcifront_scan_root(struct pcifront_device *pdev,
                                 unsigned int domain, unsigned int bus)
 {
        struct pci_bus *b;
+       LIST_HEAD(resources);
        struct pcifront_sd *sd = NULL;
        struct pci_bus_entry *bus_entry = NULL;
        int err = 0;
+       static struct resource busn_res = {
+               .start = 0,
+               .end = 255,
+               .flags = IORESOURCE_BUS,
+       };

 #ifndef CONFIG_PCI_DOMAINS
        if (domain != 0) {
@@ -470,17 +476,21 @@ static int pcifront_scan_root(struct pcifront_device *pdev,
                err = -ENOMEM;
                goto err_out;
        }
+       pci_add_resource(&resources, &ioport_resource);
+       pci_add_resource(&resources, &iomem_resource);
+       pci_add_resource(&resources, &busn_res);
        pcifront_init_sd(sd, domain, bus, pdev);

        pci_lock_rescan_remove();

-       b = pci_scan_bus_parented(&pdev->xdev->dev, bus,
-                                 &pcifront_bus_ops, sd);
+       b = pci_scan_root_bus(&pdev->xdev->dev, bus,
+                                 &pcifront_bus_ops, sd, &resources);
        if (!b) {

Bjorn, what do you think about ?

Thanks!
Yijing.


> 
>>>>  	pcifront_init_sd(sd, domain, bus, pdev);
>>>>  
>>>>  	pci_lock_rescan_remove();
>>>>  
>>>> -	b = pci_scan_bus_parented(&pdev->xdev->dev, bus,
>>>> -				  &pcifront_bus_ops, sd);
>>>> +	b = pci_scan_root_bus(&pdev->xdev->dev, bus,
>>>> +				  &pcifront_bus_ops, sd, &resources);
>>>>  	if (!b) {
>>>>  		dev_err(&pdev->xdev->dev,
>>>>  			"Error creating PCI Frontend Bus!\n");
>>>>  		err = -ENOMEM;
>>>>  		pci_unlock_rescan_remove();
>>>> +		pci_free_resource_list(&resources);
>>>>  		goto err_out;
>>>>  	}
>>>>  
>>>> @@ -488,7 +494,7 @@ static int pcifront_scan_root(struct pcifront_device *pdev,
>>>>  
>>>>  	list_add(&bus_entry->list, &pdev->root_buses);
>>>>  
>>>> -	/* pci_scan_bus_parented skips devices which do not have a have
>>>> +	/* pci_scan_root_bus skips devices which do not have a
>>>>  	* devfn==0. The pcifront_scan_bus enumerates all devfn. */
>>>>  	err = pcifront_scan_bus(pdev, domain, bus, b);
>>>>  
>>>> -- 
>>>> 1.7.1
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>>> the body of a message to majordomo@...r.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>> .
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> .
> 


-- 
Thanks!
Yijing

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/