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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 26 Apr 2010 14:12:35 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Jesse Barnes" <jbarnes@...tuousgeek.org>
Cc:	"Bjorn Helgaas" <bjorn.helgaas@...com>,
	"Andy Isaacson" <adi@...apodia.org>,
	"R. Andrew Bailey" <bailey@...mai.com>,
	"Yinghai" <yinghai.lu@...cle.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Ingo Molnar" <mingo@...hat.com>, guenter.roeck@...csson.com,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Thomas Renninger" <trenn@...e.de>, yaneti@...lera.com
Subject: Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below 
 BIOS_END

> On Mon, 26 Apr 2010 14:27:56 -0600
> Bjorn Helgaas <bjorn.helgaas@...com> wrote:
>> I'm a little concerned that those patches are a sledgehammer approach.
>> Previously, IORESOURCE_BUSY has basically been used for mutual exclusion
>> between drivers that would otherwise claim the same resource.  It hasn't
>> been used to guide resource assignment in the PCI/PNP/etc core.  Maybe
>> it's a good idea to also use IORESOURCE_BUSY there, but I'm not sure.
>> Right now it feels like undesirable overloading to me.
>
> I guess that's true, removing those regions from the pool entirely
> might be better?  Or some other, clear way of expressing that the
> regions aren't available to drivers.  Maybe we need a new IO resource
> type for platform ranges.
>
>> I think it also leads to at least one problem: Guenter's machine has no
>> VGA but has a PCI device that lives at 0xa0000.  The driver for that
>> device won't be able to request that region if the arch code has marked
>> it busy.
>
> Ah good point, so we'll want another approach at any rate.  Yinghai?

What we need is to keep track of the areas available for address space
allocation by dynamically addressed devices, as distinct from address
space that is in use by a kernel-known device.  There is an in-between,
which one can call "here there be dragons" space, which should never be
used for dynamic device allocation, but if a platform device or
pre-assigned device uses that space then it should be allowed to be
allocated.

In the case of x86, anything that is E820_RESERVED, *or* in the legacy
region (below 1 MB) and is not RAM, is "here there be dragons" space.

    -hpa

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ