[PATCH 2.4 and 2.6] trim.bottom trims the wrong entry

["Luck, Tony" <tony.luck@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

This was a fun one to track down.  I was trying to provide
a fake SRAT table so that I could start working on some more
ccNUMA issues on a non-NUMA tiger box, but my kernel kept dying
while running scripts out of /etc/init.d/*

I found I was getting an MCA while executing an lfetch.excl in
clear_page_tables(), the address that was being fetched was
0xe0000000000a00e8, which is non-cacheable VGA memory on Tiger.

Root cause was the "trim" code in efi_memmap_walk() had failed
to trim away all the blocks of memory in the bottom granule when
it had seen the memory hole there, so the kernel had managed to
allocate a page at 0x9c000 as a page table, and when the process
using it ended, the cleanup code prefetched off the end of the
page, and into the VGA memory, causing an MCA.

The problem is that efi_memmap_walk() repeatedly trims the same
entry, instead of trimming each of the entries in the granule.

-Tony

[-- Attachment #2: trim.patch --]
[-- Type: application/octet-stream, Size: 397 bytes --]

diff -ru a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
--- a/arch/ia64/kernel/efi.c	Wed Aug 27 15:49:27 2003
+++ b/arch/ia64/kernel/efi.c	Wed Aug 27 16:47:27 2003
@@ -324,7 +324,7 @@
 				check_md = q;
 
 				if (check_md->attribute & EFI_MEMORY_WB)
-					trim_bottom(md, granule_addr);
+					trim_bottom(check_md, granule_addr);
 
 				if (check_md->phys_addr < granule_addr)
 					continue;