On Mon, Jun 20, 2016 at 8:29 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, Jun 20, 2016 at 7:38 AM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: >> >> Overall, we seem to be heading towards the "really weird" territory here. > > So the whole commit that Boris bisected down to is weird to me. > > Why isn't the temporary text mapping just set up unconditionally in > the temp_level4_pgt? > > Why does it have that insane "let's leave the temp_level4_pgt alone > until we actually switch to it, and save away restore_pgd_addr and the > restore_pgd, to then be set up at restore time"? > > All the other temporary mappings are set up statically in the > temp_level4_pgt, why not that one? The text mapping in temp_level4_pgt has to map the image kernel's physical entry address to the same virtual address that the image kernel had for it, because the image kernel will switch over to its own page tables first and it will use its own kernel text mapping from that point on. That may not be the same as the text mapping of the (currently running) restore (or "boot") kernel. So if we set up the text mapping in temp_level4_pgt upfront, we basically can't reference the original kernel text (or do any addressing relative to it) any more after switching over to temp_level4_pgt. For some reason I thought that was not doable, but now that I look at the code it looks like it can be done. I'll try doing that. > I suspect whatever corruption happens boils down to the same issue > that made people do that odd decision in the first place. The breakage appears to happen regardless of these changes, though. > And regardless, those games are too ugly to live. So I would suggest > that that original commit should just be considered broken, and > reverted (or just removed - I'm not sure if it's in a stable branch or > not) and the fix be rethought so that the code mapping can be done > once and for all and *without* the extra games. OK Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html