All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Borislav Petkov <bp@alien8.de>,
	Logan Gunthorpe <logang@deltatee.com>,
	Kees Cook <keescook@chromium.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>,
	John Stultz <john.stultz@linaro.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Stable <stable@vger.kernel.org>,
	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: ktime_get_ts64() splat during resume
Date: Mon, 20 Jun 2016 23:15:18 +0200	[thread overview]
Message-ID: <CAJZ5v0grcXRW6tukVmyZ3Xi0PqXSyf0+swfOLjxJkNawsSP-QA@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFwGshPVCeBeMbY_RYrA+UR7-jLjy4SCbcHTxQ=f2KwESA@mail.gmail.com>

On Mon, Jun 20, 2016 at 8:29 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Jun 20, 2016 at 7:38 AM, Rafael J. Wysocki <rjw@rjwysocki.net> 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

  reply	other threads:[~2016-06-20 21: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 [this message]
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
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=CAJZ5v0grcXRW6tukVmyZ3Xi0PqXSyf0+swfOLjxJkNawsSP-QA@mail.gmail.com \
    --to=rafael@kernel.org \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=dvlasenk@redhat.com \
    --cc=hpa@zytor.com \
    --cc=john.stultz@linaro.org \
    --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=stable@vger.kernel.org \
    --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.