From: Thomas Gleixner <tglx@linutronix.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Xi Ruoyao <xry111@mengyan1223.wang>,
Jiri Kosina <jikos@kernel.org>, Kees Cook <keescook@chromium.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
Borislav Petkov <bp@alien8.de>, Len Brown <lenb@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Tony Luck <tony.luck@intel.com>,
Bob Moore <robert.moore@intel.com>,
Erik Schmauss <erik.schmauss@intel.com>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Nadav Amit <namit@vmware.com>
Subject: Re: [GIT PULL] x86/topology changes for v5.3
Date: Wed, 10 Jul 2019 16:26:02 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.1907101622580.1758@nanos.tec.linutronix.de> (raw)
In-Reply-To: <alpine.DEB.2.21.1907101555510.1758@nanos.tec.linutronix.de>
On Wed, 10 Jul 2019, Thomas Gleixner wrote:
> On Wed, 10 Jul 2019, Peter Zijlstra wrote:
>
> > On Wed, Jul 10, 2019 at 09:25:16PM +0800, Xi Ruoyao wrote:
> > > On 2019-07-10 14:31 +0200, Jiri Kosina wrote:
> > > > Adding Daniel to check whether this couldn't be some fallout of jumplabel
> > > > batching.
> > >
> > > I don't think so. I tried to revert Daniel's jumplabel batching commits and the
> > > issue wasn't solved. But reverting Kees' CR0 and CR4 commits can "fix" it
> > > (apprently).
> >
> > Xi, could you please try the below instead?
> >
> > If we mark the key as RO after init, and then try and modify the key to
> > link module usage sites, things might go bang as described.
>
> Right. I finally was able to reproduce that with Linus' config (slightly
> modified). Applying your patch makes it go away.
>
> Now what puzzles me is that this never exploded in my face before and with
> a debian config it JustWorks.
>
> Both configs have:
>
> CONFIG_KVM=m
> CONFIG_KVM_INTEL=m
>
> so I'd expect both to crash and burn when KVM_INTEL is loaded as that has a
> cr4 operation inside.
>
> So something papers over that ... Still looking.
Just found it. All my usual configs have the paravirt muck enabled. Linus's
config does not, neither has Xi's.
With paravirt the CR pinning key is never in the module. It's in the
paravirt function and obviously always built in.
Thanks,
tglx
next prev parent reply other threads:[~2019-07-10 14:26 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-08 16:27 [GIT PULL] x86/topology changes for v5.3 Ingo Molnar
2019-07-09 1:45 ` pr-tracker-bot
2019-07-09 21:20 ` Linus Torvalds
2019-07-09 21:26 ` Linus Torvalds
2019-07-09 21:45 ` Linus Torvalds
2019-07-09 22:00 ` Linus Torvalds
2019-07-09 22:07 ` Linus Torvalds
2019-07-09 22:27 ` Thomas Gleixner
2019-07-09 23:00 ` Thomas Gleixner
2019-07-09 23:17 ` Thomas Gleixner
2019-07-10 0:31 ` Kees Cook
2019-07-10 11:27 ` Xi Ruoyao
2019-07-10 12:01 ` Xi Ruoyao
2019-07-10 12:19 ` Thomas Gleixner
2019-07-10 12:31 ` Jiri Kosina
2019-07-10 13:21 ` Peter Zijlstra
2019-07-10 13:27 ` Jiri Kosina
2019-07-10 13:28 ` Jiri Kosina
2019-07-10 13:31 ` Xi Ruoyao
2019-07-10 13:25 ` Xi Ruoyao
2019-07-10 13:44 ` Peter Zijlstra
2019-07-10 14:03 ` Thomas Gleixner
2019-07-10 14:26 ` Thomas Gleixner [this message]
2019-07-10 14:22 ` Jiri Kosina
2019-07-10 14:26 ` Peter Zijlstra
2019-07-10 15:13 ` Thomas Gleixner
2019-07-10 15:58 ` Xi Ruoyao
2019-07-10 19:42 ` [PATCH] x86/asm: Move native_write_cr0/3() out of line Thomas Gleixner
2019-07-10 19:59 ` Kees Cook
2019-07-10 20:00 ` Thomas Gleixner
2019-07-10 20:02 ` Peter Zijlstra
2019-07-10 20:19 ` [tip:x86/urgent] x86/asm: Move native_write_cr0/4() " tip-bot for Thomas Gleixner
2019-07-10 14:44 ` [GIT PULL] x86/topology changes for v5.3 Xi Ruoyao
2019-07-11 7:11 ` Nadav Amit
2019-07-11 7:16 ` Thomas Gleixner
2019-07-11 8:01 ` Peter Zijlstra
2019-07-11 15:08 ` Kees Cook
2019-07-11 17:09 ` Nadav Amit
2019-07-10 0:59 ` Linus Torvalds
2019-07-10 1:08 ` Linus Torvalds
2019-07-10 3:21 ` Linus Torvalds
2019-07-10 5:15 ` Linus Torvalds
2019-07-10 5:33 ` Kees Cook
2019-07-10 18:40 ` Linus Torvalds
2019-07-10 10:03 ` 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=alpine.DEB.2.21.1907101622580.1758@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=bristot@redhat.com \
--cc=erik.schmauss@intel.com \
--cc=jikos@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namit@vmware.com \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=robert.moore@intel.com \
--cc=tony.luck@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=xry111@mengyan1223.wang \
/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).