linux-kernel - Re: acpi based pci gap calculation

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]

Message-Id: <1216833034.6354.12.camel@alok-dev1>
Date:	Wed, 23 Jul 2008 10:10:34 -0700
From:	Alok Kataria <akataria@...are.com>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Andi Kleen <ak@...ux.intel.com>, Ingo Molnar <mingo@...e.hu>,
	Len <len.brown@...el.com>, LKML <linux-kernel@...r.kernel.org>,
	linux-acpi <linux-acpi@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	TJ <linux@...orld.net>
Subject: Re: acpi based pci gap calculation  - v3

Hi Jesse,

On Wed, 2008-07-23 at 09:58 -0700, Jesse Barnes wrote:
> On Tuesday, July 22, 2008 3:52 pm Alok Kataria wrote:
> > So the gap that we had calculated first i.e. from e820_setup_gap did
> > contain a collision i.e. though a resource was reserved from
> > [0xf0000000 - 0xf7ffffff] our gap calculation doesn't take that into
> > account.  My patch fixes this issue.
> >
> > So, IMHO this is a BUG and should be fixed. Please let me know your
> > views.
> 
> Yes, there's a conflict there, but on many machines it's probably a harmless
> one.  My main concerns are these:
>   1) it changes long standing behavior and doesn't fix any real reported bugs
>      I'm aware of (feel free to point me at some)

The problem that I see is with Memory Hotadd, though my BIOS exports the
correct SRAT table and tells the OS that some regions are hot pluggable,
PCI gap calculation ignores that info and assigns some "option ROMS" in
hot pluggable memory region. 

Because of this when i try to hot add memory, the OS sees a resource
allocation conflict and bails out. Which shouldn't have happened,
right ?

>   2) it looks like it will dramatically reduce the available PCI resource
>      space on at least some platforms, and that space is already scarce in our
>      current scheme

IMO, these gaps are used only for the option ROMS or hot pluggable
devices which in itself are rare. So its not like we are reducing the
whole available PCI resource space, but only the space that is needed by
these optional ROMS.
And i think its inevitable if we have to remove these conflicts with any
other subsystem. 
> 
> So basically, I'm just feeling very conservative about any changes to resource
> allocation, that's all.
> 
> If this change were coupled with one that allowed us to exploit more available
> address space for PCI resources I'd feel much more comfortable about it,
> which is why I'm so interested in TJ's work (/me goes off to read his wiki
> now).

/me to having a look.

Thanks,
Alok
> 
> Thanks,
> Jesse

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