linux-kernel - Re: More E820 brokenness

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 27 Sep 2007 17:34:08 -0600
From:	"Jordan Crouse" <jordan.crouse@....com>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	jkeating@...hat.com, "Joerg Pommnitz" <pommnitz@...oo.com>,
	"Chuck Ebbert" <cebbert@...hat.com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Andi Kleen" <ak@...e.de>
Subject: Re: More E820 brokenness

On 27/09/07 16:27 -0700, H. Peter Anvin wrote:
> Jordan Crouse wrote:
> > On 27/09/07 15:47 -0700, H. Peter Anvin wrote:
> >> Jordan Crouse wrote:
> >>> Breaks on the Geode - original behavior.
> >>>
> >>> I think that having boot_prams.e820_entries != 0 makes the kernel
> >>> assume the e820 data is correct.
> >>>
> >> Okay, now I'm utterly baffled how 2.6.22 ever worked on this Geode,
> >> because this, to the best of my reading, mimics the 2.6.22 behavior
> >> exactly.  DID IT REALLY, and/or did you make any kind of configuration
> >> changes?
> > 
> > I copied in a 2.6.22 kernel to see that it really did work, and it did.
> > But here's the crazy part - I did a dmesg, and it looks like it
> > *is* using e820 data, and it looks complete (I see the entire map - 
> > including the ACPI and reserved blocks way up high).
> > 
> > So apparently it was the 2.6.22 code that was buggy, but reading it,
> > I don't immediately see how. 
> > 
> 
> Oh bugger, looks like this one might be genuinely my fault after all.
> The ID check in the new code is buggy.
> 
> Can you please test this revised patch out (against current -git)?

> 	-hpa
> 
> 
> 

> diff --git a/arch/i386/boot/memory.c b/arch/i386/boot/memory.c
> index bccaa1c..84939b7 100644
> --- a/arch/i386/boot/memory.c
> +++ b/arch/i386/boot/memory.c
> @@ -34,17 +34,7 @@ static int detect_memory_e820(void)
>  		      "=m" (*desc)
>  		    : "D" (desc), "a" (0xe820));
>  
> -		/* Some BIOSes stop returning SMAP in the middle of
> -		   the search loop.  We don't know exactly how the BIOS
> -		   screwed up the map at that point, we might have a
> -		   partial map, the full map, or complete garbage, so
> -		   just return failure. */
> -		if (id != SMAP) {
> -			count = 0;
> -			break;
> -		}
> -
> -		if (err)
> +		if (id != SMAP || err)
>  			break;
>  
>  		count++;


That looks the same as the previous patch you sent?

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.


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