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@xxxxxxxxxxxxx>".
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 kernel-testers" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
