From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>, X86 ML <x86@kernel.org>,
Borislav Petkov <bpetkov@suse.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 2/2] x86/hibernate/64: Mask off CR3's PCID bits in the saved CR3
Date: Mon, 11 Sep 2017 07:48:19 +0200 [thread overview]
Message-ID: <20170911054819.2dnlrhwc6myf7iog@gmail.com> (raw)
In-Reply-To: <CALCETrXkciEUPgU_vJEzV=VY7WSG7gLRYGy1gBgurHJg3ZYung@mail.gmail.com>
* Andy Lutomirski <luto@kernel.org> wrote:
> On Fri, Sep 8, 2017 at 12:59 AM, Jiri Kosina <jikos@kernel.org> wrote:
> > On Thu, 7 Sep 2017, Andy Lutomirski wrote:
> >
> >> Jiri reported a resume-from-hibernation failure triggered by PCID.
> >> The root cause appears to be rather odd. The hibernation asm
> >> restores a CR3 value that comes from the image header. If the image
> >> kernel has PCID on, it's entirely reasonable for this CR3 value to
> >> have one of the low 12 bits set. The restore code restores it with
> >> CR4.PCIDE=0, which means that those low 12 bits are accepted by the
> >> CPU but are either ignored or interpreted as a caching mode. This
> >> is odd, but still works. We blow up later when the image kernel
> >> restores CR4, though, since changing CR4.PCIDE with CR3[11:0] != 0
> >> is illegal. Boom!
> >>
> >> FWIW, it's entirely unclear to me what's supposed to happen if a PAE
> >> kernel restores a non-PAE image or vice versa. Ditto for LA57.
> >
> > I've just performed 15 hibernation cycles with current Linus' tree
> > (5969d1bb3082) with these two patches applied on top of it, and I haven't
> > encountered any issue (and the warning in switch_mm_irqs_off() didn't
> > trigger either).
> >
> >> Reported-by: Jiri Kosina <jikos@kernel.org>
> >> Fixes: 660da7c9228f ("x86/mm: Enable CR4.PCIDE on supported systems")
> >> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> >
> > Tested-by: Jiri Kosina <jkosina@suse.cz>
> >
>
> Ingo, please do *not* apply this patch yet. The code is fine, but the
> comment is about to become wrong. I just found a nasty initialization
> order issue, and I need to rework a bunch of the way we deal with
> PCIDE.
Ok, I'll delay everything PCID delayed - once you've gathered it all together
please send a full series against Linus's latest collecting all the
fixes/cleanups.
If you find unexpected complications then there will be a point in time where it
might be better to just disable PCID for this release and re-try in v4.15. As the
number and complexity of fixes increases so does the risk that we'll introduce
some last-minute regression.
Thanks,
Ingo
next prev parent reply other threads:[~2017-09-11 5:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-08 5:06 [PATCH 0/2] More PCID fixes Andy Lutomirski
2017-09-08 5:06 ` [PATCH 1/2] x86/mm: Get rid of VM_BUG_ON in switch_tlb_irqs_off() Andy Lutomirski
2017-09-08 5:09 ` Andy Lutomirski
2017-09-13 8:55 ` [tip:x86/urgent] " tip-bot for Andy Lutomirski
2017-09-08 5:06 ` [PATCH 2/2] x86/hibernate/64: Mask off CR3's PCID bits in the saved CR3 Andy Lutomirski
2017-09-08 7:59 ` Jiri Kosina
2017-09-10 19:17 ` Andy Lutomirski
2017-09-11 5:48 ` Ingo Molnar [this message]
2017-09-13 8:55 ` [tip:x86/urgent] " tip-bot for Andy Lutomirski
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=20170911054819.2dnlrhwc6myf7iog@gmail.com \
--to=mingo@kernel.org \
--cc=bpetkov@suse.de \
--cc=jikos@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.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.