All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Kees Cook <keescook@chromium.org>, Borislav Petkov <bp@alien8.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	lkml <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Brian Gerst <brgerst@gmail.com>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Linux PM list <linux-pm@vger.kernel.org>,
	Stephen Smalley <sds@tycho.nsa.gov>
Subject: Re: [PATCH v3] x86/power/64: Fix kernel text mapping corruption during image restoration
Date: Thu, 30 Jun 2016 14:16:31 +0200	[thread overview]
Message-ID: <CAJZ5v0hHzb_vQ94XL+C6kpKJW_DkdenCzbQBLN=ucZT9OE5cdQ@mail.gmail.com> (raw)
In-Reply-To: <8273253c-95dd-0156-7af8-d2a164d1491b@deltatee.com>

On Thu, Jun 30, 2016 at 5:56 AM, Logan Gunthorpe <logang@deltatee.com> wrote:
>
>
> On 29/06/16 08:55 PM, Rafael J. Wysocki wrote:
>
>> The only thing that comes to mind at this point is that TLBs should be
>> flushed
>> after page tables changes, so please apply the appended and let me know
>> if you see this panic any more with it.
>
>
>
> Ok, I'll build a new kernel tomorrow.

Well, please wait for a while.

I'm looking at the panic log right now and the picture is a bit clearer now.

> But keep in mind the panic is pretty
> rare as I've only seen it once so far after a couple dozen or so hibernates.
> So it may be hard to get a concrete yes or no on whether it fixes the issue.

Right.

> I've got a script to run a bunch of hibernates in a row. I usually only run
> it for a handful of iterations, but I'll try running it for much longer with
> this patch and let you know in a couple days.

As I said, please wait a bit, there may be updates in the meantime. :-)

>From looking at your panic log, the exception happened in
swsusp_arch_resume(), which probably covers restore_image() too,
because that is likely to go into swsusp_arch_resume() in line.

Next, the address in RIP (a) clearly is a page start and (b) is
relative to the identity mapping, so it most likely is the address
from relocated_restore_code.  Moreover, the RCX value is the same
address and the values in the other registers also match exactly the
situation before the jump to relocated_restore_code.  Thus the
exception was triggered by that jump beyond doubt.

Now, if you look above the Oops line, it becomes quite clear what
happened.  Namely, dump_pagetable() (arch/x86/mm/fault.c, line 524 in
4.6) prints the PGD, the PUD, the PMD and the PTE in that order,
unless the lower levels (PTE, PMD) are not present.  In your panic
log, only the PGD and PUD are present, meaning that this is a 1G page
and sure enough it has the NX bit set.

This case was clearly overlooked by relocate_restore_code(), so
updated patch will follow.

Thanks,
Rafael

  reply	other threads:[~2016-06-30 12:16 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-17 10:54 ktime_get_ts64() splat during resume Borislav Petkov
2016-06-17 11:53 ` Thomas Gleixner
2016-06-17 13:29   ` Borislav Petkov
2016-06-17 14:33     ` Borislav Petkov
2016-06-17 15:28       ` Rafael J. Wysocki
2016-06-17 16:12         ` Borislav Petkov
2016-06-17 21:03           ` Rafael J. Wysocki
2016-06-18  1:11             ` Rafael J. Wysocki
2016-06-20 14:38             ` Rafael J. Wysocki
2016-06-20 18:29               ` Linus Torvalds
2016-06-20 21:15                 ` Rafael J. Wysocki
2016-06-21  0:05                   ` Rafael J. Wysocki
2016-06-21  1:22                     ` Rafael J. Wysocki
2016-06-21  4:35                       ` Logan Gunthorpe
2016-06-21 11:36                         ` Rafael J. Wysocki
2016-06-21 18:04                         ` Kees Cook
2016-06-21 23:29                           ` Rafael J. Wysocki
2016-06-27 14:24                           ` [PATCH v3] x86/power/64: Fix kernel text mapping corruption during image restoration (was: Re: ktime_get_ts64() splat during resume) Rafael J. Wysocki
2016-06-27 20:08                             ` Borislav Petkov
2016-06-27 23:33                             ` [PATCH v3] x86/power/64: Fix kernel text mapping corruption during image restoration Logan Gunthorpe
2016-06-29 14:48                               ` Kees Cook
2016-06-30  1:52                                 ` Logan Gunthorpe
2016-06-30  2:20                                   ` Rafael J. Wysocki
2016-06-30  2:55                                     ` Rafael J. Wysocki
2016-06-30  3:56                                       ` Logan Gunthorpe
2016-06-30 12:16                                         ` Rafael J. Wysocki [this message]
2016-06-30  9:45                                     ` Borislav Petkov
2016-06-30 11:27                                       ` Rafael J. Wysocki
2016-06-30 13:17                             ` [PATCH v4] " Rafael J. Wysocki
2016-06-30 15:05                               ` Borislav Petkov
2016-06-30 15:17                                 ` Rafael J. Wysocki
2016-06-30 15:24                                   ` Andy Lutomirski
2016-06-30 15:29                                     ` Rafael J. Wysocki
2016-06-30 17:23                                       ` Andy Lutomirski
2016-06-30 16:11                               ` [PATCH v5] " Rafael J. Wysocki
2016-06-30 17:02                                 ` Borislav Petkov
2016-06-30 21:47                                 ` Logan Gunthorpe
2016-06-20  8:17         ` ktime_get_ts64() splat during resume chenyu
2016-06-20 12:21           ` 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='CAJZ5v0hHzb_vQ94XL+C6kpKJW_DkdenCzbQBLN=ucZT9OE5cdQ@mail.gmail.com' \
    --to=rafael@kernel.org \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=dvlasenk@redhat.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rjw@rjwysocki.net \
    --cc=sds@tycho.nsa.gov \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.