linux-kernel - Re: [PATCH 3/3] PCI: allocate bus resources from the top down

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:	Thu, 16 Sep 2010 10:44:08 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
CC:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Brian Bloniarz <phunge0@...mail.com>,
	Charles Butterfield <charles.butterfield@...tcentury.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	Stefan Becker <chemobejk@...il.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 3/3] PCI: allocate bus resources from the top down

On 09/16/2010 10:04 AM, Bjorn Helgaas wrote:
> It does seem like we should do *something* with E820 reserved areas, but
> I'm not 100% convinced we should be more strict than Windows.  If we
> pay attention to things Windows doesn't test, I think we're likely to
> trip over even more BIOS bugs.

Windows have a couple of advantages on us.  They have WHQL; every
machine needs to pass WHQL or it doesn't get sold.  The other advantage
is that most manufacturers of Windows desktops don't give a damn about
anything other than the shipping configuration (Windows version and
hardware): I have seen machines which fail to boot if you put in a PCI
UART card.

> Linux does avoid putting PCI devices in E820 reserved areas ... in
> some cases.  In this Dell case, the reserved area conflicts with a
> host bridge window, so we expand the reserved area and insert it as
> the *parent* of the window.  Since it's the parent, it has no effect
> on allocations from the window, so we end up putting devices in the
> reserved area.

OK, so that's a problem.  This isn't really a hideously uncommon use
case for a reserved region, either: it probably reflects a device used
by SMM under that particular host bridge.

> I think the problem is that E820 reservations fundamentally don't
> fit well with the Linux resource manager.  We manage resources as
> a strict hierarchy of non-overlapping regions, but there's no
> requirement that E820 reservations have any relationship with actual
> devices that we discover via ACPI, PCI, etc.
> 
> We've been kludging around this with a collection of hacks like
> reserve_region_with_split() and insert_resource_expand_to_fit(),
> but I think we're just making an unmaintainable mess.  We should
> take a step back and think about how to do this cleanly.

Perhaps we should consider reserved regions a separate hierarchy, or we
should deal with them at the time a new resource is created?

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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