On Tue, Aug 9, 2016 at 10:02 PM, Jiri Kosina <ji...@kernel.org> wrote: > On Tue, 9 Aug 2016, Rafael J. Wysocki wrote: > >> I have a murky suspicion, but it is really weird. Namely, what if >> restore_jump_address in set_up_temporary_text_mapping() happens to be >> covered by the restore kernel's identity mapping? Then, the image >> kernel's entry point may get overwritten by something else in >> core_restore_code(). > > So this made me to actually test a scenario where I'd suspend a kernel > that's known-broken (i.e. contains 021182e52fe), and then have it resumed > by a kernel that has 021182e52fe reverted. It resumed successfully. > > Just a datapoint.
That indicates the problem is somewhere in the restore kernel and no surprises there. I am able to reproduce the original problem (a triple fault on resume with CONFIG_RANDOMIZE_MEMORY set) without the $subject patch, but the patch fixes it for me. Question is why it is not sufficient for you and Boris and the above theory is about the only one I can come up with ATM. I'm going to compare the configs etc, but I guess I just end up writing a patch to test that theory unless someone has any other idea in the meantime. Thanks, Rafael
