lkml.org 
[lkml]   [2016]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk
On Thu, Jul 28, 2016 at 12:12:15AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 27, 2016 12:59:18 PM Josh Poimboeuf wrote:
> > Hm... I have a theory, but I'm not sure about it. I noticed that
> > x86_acpi_enter_sleep_state(),
>
> I think you mean x86_acpi_suspend_lowlevel().

Oops!

> > which is involved in suspend, overwrites
> > several global variables (e.g, initial_code) which are used by the CPU
> > boot code in head_64.S. But surprisingly, it doesn't restore those
> > variables to their original values after it resumes.
>
> Is the head_64.S code also used to bring up offline CPUs?

Yes.

> If not, then this is not the problem, because hibernation doesn't use it
> for the boot CPU anyway.
>
> > So if a suspend and resume were done before the hibernate, those
> > variables would presumably have suspend-centric values, and the first
> > time a CPU is brought up during the hibernation restore operation, it
> > would jump to wakeup_long64() (the suspend resume function) instead of
> > start_secondary (which is the normal CPU boot function).
> >
> > So, if true, that would explain why my patch triggers a bug:
> > wakeup_long64() always[*] jumps to .Lresume_point, which my patch
> > affected. Because of the FRAME_END, it would pop an extra value off the
> > stack. So when restore_processor_state() returns, it would return to
> > whatever random address is on the stack after the real RIP. Which is
> > consistent with the oops from the bug. It had a bad instruction
> > pointer, which looked like a stack address.
>
> OK, so why doesn't it break resume from suspend to RAM?

Because for suspend to RAM, it enters suspend through
do_suspend_lowlevel(), which has the FRAME_BEGIN which corresponds to
.Lresume_point's FRAME_END.

> wakeup_long64 is invoked by the CPU startup code then and doesn't the
> FRAME_END affect that too?

Yes, I would imagine that any CPU startup operation (after
suspend/resume to RAM) would be affected.

--
Josh

\
 
 \ /
  Last update: 2016-07-28 01:01    [W:0.143 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site