Re: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, 29 Aug 2008, Yinghai Lu wrote:
> 
> if we don't add the IORESOURCE_BUSY, why bother to add these entries...

You don't understand how the resource allocator works.

IORESOURCE_BUSY is really more of a "legacy bit". It has almost no bearing 
on the actual allocations.

Just grep for IORSOURCE_BUSY in kernel/resource.c. The _only_ thing that 
cares about busy/non-busy is the legact "request_region()" function. That 
one isn't actually used by any core PCI code - it's more of a driver 
issue to claim exclusive ownership of particular resources by inserting a 
marker in that resource.

So IORESOURCE_BUSY is a red herring. The only reason I said you can clear 
it is because you claimed it causes problems, but the more I look at it, 
the more I think you're likely just mistaken - because IORESOURCE_BUSY 
doesn't make any difference at all to normal resource handling until you 
get to actual drivers.

The bigger issue is that just inserting the resource (and it really 
doesn't matter if it is marked busy or not) is in itself a mark of 
"there's something here". THAT is what all the resource code cares about. 
The IORESOURCE_BUSY bit is almost immaterial (ie _is_ immaterial except 
for some very specific cases).

And the reason we need to add the e820 resources is exactly so that we 
don't try to allocate PCI resources on top of some system resources we 
don't even know about!

> good layout from BIOS, it should only reserve mmio range is not showing in BAR.

I agree, but "good layour" and "BIOS" don't really go together. There's 
too many broken BIOSes.

> if one stupid BIOS set
> 0xdc000000 - 0x100000000 for reserved.
> 
> then when in insert that range late

Sure, but really, the only point of even caring about e820 resources in 
the first place has really nothing to do with the BAR's we can see 
(because the kernel can handle _those_ perfectly well on its own), and has 
everything to do with teh fact that a lot of devices have invisible 
resources that we _cannot_ see (ie magic non-standard BAR's for the 
motherboard chips).

And those are exactly why we want to populate the resource map with the 
e820 information - to avoid having dynamic resources (like Cardbus or PCI 
hotplug, or just devices that weren't set up statically by the BIOS) be 
then allocated by the kernel on top of those "invisible" resources.

And the dynamic code actually doesn't care about IORESOURCE_BUSY at all: 
it will avoid _any_ resource it can see. Think about it: it has to - since 
existing PCI resources we have set up will _not_ have that IORESOURCE_BUSY 
set.

In many ways, IORESOURCE_BUSY is pure legacy stuff, and is meant for "this 
is a black hole and you must not look into it at all". It originates with 
a need to originally having to lock drivers away from other drives by 
marking their resources busy - in an ISA world, where there are no other 
ways of saying "I own this device".

(Yeah, yeah, PCI drivers do the same thing too - they mark their BAR's by 
inserting a per-driver entry in the BAR to say 'I own this resource').

But this is where adding the e820 resources _after_ doing PCI discovery 
comes in. We don't want to clash with PCI discovery per se - we just want 
to make sure that later allocations don't allocate over anything that we 
either saw earlier (the BAR's we found set up in regular PCI discovery) 
_or_ anything that the system has said is reserved (e820 reserved 
entries).

Doing it before obviously works too - in fact, it has worked for us for 
years. But it does mean that we consider the e820 reserved areas _so_ 
reserved that we don't allow PCI BAR's in them. Which is apparently a 
mistake.

We want to consider them so reserved that we don't add _new_ PCI resources 
to them (and perhaps we might even want to stop regular PCI drivers from 
attaching to them), but not so exclusive that we don't allow BARs that 
have been set up by the BIOS in them.

			Linus