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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox