linux-kernel - Re: [PATCH v6 10/30] PCI: Introduce pci_host_bridge

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]

Date:	Fri, 13 Mar 2015 09:33:29 -0500
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Yijing Wang <wangyijing@...wei.com>
Cc:	Jiang Liu <jiang.liu@...ux.intel.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Yinghai Lu <yinghai@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Marc Zyngier <marc.zyngier@....com>,
	linux-arm <linux-arm-kernel@...ts.infradead.org>,
	Russell King <linux@....linux.org.uk>,
	"x86@...nel.org" <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" <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>
Subject: Re: [PATCH v6 10/30] PCI: Introduce pci_host_bridge_list to manage
 host bridges

On Thu, Mar 12, 2015 at 10:28 PM, Yijing Wang <wangyijing@...wei.com> wrote:
>>>> It's a nice idea to move this test into the core.  While you're at it, why
>>>> don't you check for any overlap with the bus ranges of existing host
>>>> bridges?  For example, if we're trying to create a new host bridge to
>>>> [bus 40-7f], it should conflict with existing bridges to [bus 00-7f]
>>>> as well as to [bus 40-ff].  I think your current patch will detect the
>>>> latter conflict but not the former.
>>>
>>> Now pci host bridge may only know its start bus number, like acpi _BBN provided,
>>> but does not limit the end bus number, Eg. two pci roots report _BBN 0x0 and 0x80,
>>> so we have two bus number resource (0, 0xff) and (0x80, 0xff), if we check it strictly,
>>> some pci scan would fail which currently scan success.
>>
>> _BBN is not the correct source for the bridge's bus number range.  There's
>> a comment in acpi_pci_root_add() that explains why:
>>
>>   * We need both the start and end of the downstream bus range
>>   * to interpret _CBA (MMCONFIG base address), so it really is
>>   * supposed to be in _CRS.  If we don't find it there, all we
>>   * can do is assume [_BBN-0xFF] or [0-0xFF].
>>
>> A platform SHOULD know the start and and end bus number.  If it doesn't I
>> think it's the platform's responsibility to carve up the bus number range.
>> Maybe this can be done by trimming the range of the [bus 00-ff] bridge when
>> we discover another bridge that leads to bus 80.
>
> Currently, if platform does not know the end bus number (not provide the bus resource),
> we will update the max bus number returned by pci_scan_child_bus() to the bus resource end,
> and I think this is reasonable. I consider to introduce a flag to identify the bus resource
> which end bus number is undefined, then we could force all pci_scan_root_bus()  etc. callers
> to provide the bus resource, and we could process the bus resource end according the bus resource flag.
> Also then we could reduce the bus argument which is the same as busn_res->start.
> I would try to provide draft patch, then we could discuss it more clearly.

Without having seen a patch, my inclination is to avoid a flag because
flags change the behavior of the code you call, which makes that code
harder to follow.  Maybe we could require these platforms to
explicitly update the ending bus number after scanning the bus.

Bjorn
--
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/