From: Josh Poimboeuf <jpoimboe@redhat.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Ingo Molnar <mingo@kernel.org>, Borislav Petkov <bp@suse.de>,
Pavel Machek <pavel@ucw.cz>,
Linux PM list <linux-pm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
shuzzle@mailbox.org
Subject: Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk
Date: Wed, 27 Jul 2016 17:17:38 -0500 [thread overview]
Message-ID: <20160727221738.ilmm6mnvlmzmvfnt@treble> (raw)
In-Reply-To: <2037077.DPom3MoXJk@vostro.rjw.lan>
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
next prev parent reply other threads:[~2016-07-27 22:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-26 11:32 Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk Rafael J. Wysocki
2016-07-26 14:04 ` Borislav Petkov
2016-07-26 20:24 ` Rafael J. Wysocki
2016-07-26 20:33 ` Kees Cook
2016-07-26 20:53 ` Rafael J. Wysocki
2016-07-26 20:59 ` Kees Cook
2016-07-26 21:17 ` Thomas Garnier
2016-07-27 5:39 ` Borislav Petkov
2016-07-26 14:39 ` Josh Poimboeuf
2016-07-26 20:15 ` Rafael J. Wysocki
2016-07-26 20:31 ` Kees Cook
2016-07-26 20:42 ` Rafael J. Wysocki
2016-07-26 21:53 ` Josh Poimboeuf
2016-07-26 22:42 ` Rafael J. Wysocki
2016-07-26 23:08 ` Rafael J. Wysocki
2016-07-27 17:59 ` Josh Poimboeuf
2016-07-27 22:12 ` Rafael J. Wysocki
2016-07-27 22:17 ` Josh Poimboeuf [this message]
2016-07-27 23:20 ` Rafael J. Wysocki
2016-07-27 23:29 ` Rafael J. Wysocki
2016-07-28 15:17 ` [PATCH] x86/asm/power: Fix hibernation return address corruption Josh Poimboeuf
2016-07-28 15:32 ` Josh Poimboeuf
2016-07-28 21:36 ` Rafael J. Wysocki
2016-07-29 7:16 ` Ingo Molnar
2016-07-27 22:20 ` Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160727221738.ilmm6mnvlmzmvfnt@treble \
--to=jpoimboe@redhat.com \
--cc=bp@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pavel@ucw.cz \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=shuzzle@mailbox.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).