Re: PCI memory allocation bug with CONFIG_HIGHMEM

[Linus Torvalds]

On Wed, 7 Jan 2004, Eric W. Biederman wrote:
> 
> However insert_resource does not quite match what I think needs to
> happen.  After a pci quirk applies insert_resource I will get
> something like:
> 
> fff0000-ffffffff : BIOS ROM Window
>   ffff0000-ffffffff : reserved
> 
> With the reserved region still present and marked as BUSY.

I would suggest ignoring it. Not only because being overly complicated is 
bad, but simply because nobody should care. 

At some point adding extra regions is _purely_ for "documentation" 
reasons, and while that may be nice, it's not worth worrying about. The 
only thing you really want from a _correctness_ standpoint is to make sure 
that nobody else will try to allocate their stuff in that area, and your 
"BIOS ROM Window" resource should do that already. 

> Would it be reasonable to write a variant of request_resource that just
> drops BIOS resources.

It would not be impossible to just have a "force_resource()" that would
simply override _any_ existing resource, but quite frankly, I'd be more
nervous about that.

We could also mark the e820 non-RAM resources with some special
IORESOURCE_TENTATIVE flag, and allow just overriding those. 

But even the simple "insert_resource()" has some potential problems: if 
the BIOS has allocated the minimal window for itself (64kB at 0xffff0000), 
and has allocated some _other_ chip at 0xfffe0000 that the kernel doesn't 
know about yet, your insert_resource() would do the wrong thing and claim 
the whole area for the BIOS writing. 

Maybe that doesn't happen, but it's something to think about.

At some point, the _correct_ answer may be: don't do complex things, and
write a bootable floppy (without any OS at all, or a really minimal one)  
to do BIOS rom updates.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/