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

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:	Fri, 29 Aug 2008 18:11:41 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Yinghai Lu <yhlu.kernel@...il.com>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jeff Garzik <jeff@...zik.org>, Tejun Heo <htejun@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	David Witbrodt <dawitbro@...global.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kernel Testers <kernel-testers@...r.kernel.org>
Subject: Re: Linux 2.6.27-rc5: System boot regression caused by commit
 a2bd7274b47124d2fc4dfdb8c0591f545ba749dd

Btw, what was the original regression that commit was 
a2bd7274b47124d2fc4dfdb8c0591f545ba749dd trying to fix?

It's not listed in that commit, even though the commit has a "Bisected-by: 
David Witbrodt <dawitbro@...global.net>".

In fact, I can find it with google by searching for

	David Witbrodt bisect

and I see that it is 3def3d6ddf43dbe20c00c3cbc38dfacc8586998f.

I'm wondering why that commit wasn't just reverted? Because now that I see 
it, I notice that _that_ is the real bug to begin with.

That commit really was buggy. NO WAY can you insert the code/bss/data 
resources before you've done e820 handling, because it may well be that 
some strange e820 table contains things that cross the resources.

So that original thing was buggy, and made x86-64 do odd thigns. They were 
doubly odd, since x86-32 did it differently (and better, I think).

Then, when actally doing the common arch/x86/kernel/setup.c, the commit 
that does so _claims_ that the common code came from the 32-bit version, 
but that doesn't seem to be true, at least wrt this thing. The current 
setup.c comes from the *broken* cleanup of setup_64.c that had been 
bisected to be broken.

And that, in turn, happened in 41c094fd3ca54f1a71233049cf136ff94c91f4ae 
("x86: move e820_resource_resources to e820.c") which also did "and make 
32-bit resource registration more like 64 bit.", so it got the bug into 
32-bit code that had been introduced in 64-bit code.

Ugh.

So why was then that other broken commit added to paper it over, even 
though the original broken commit had been bisected and the breakage was 
known to have been due to _that_?

Hmm?

Yinghai - I'm hoping that the code movement is all over and done with, but 
you need to be a _lot_ more careful here. And Ingo, this really wasn't 
very well done.

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