From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Paolo Bonzini <pbonzini@redhat.com>,
xen-devel <Xen-devel@lists.xen.org>,
Arjan van de Ven <arjan@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
KVM list <kvm@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops
Date: Thu, 1 Oct 2015 09:15:06 +0200 [thread overview]
Message-ID: <20151001071505.GA21542@gmail.com> (raw)
In-Reply-To: <CALCETrVMV2_3ywQ_t+0rsqzxMm6D9PvDEmOdrie67rRzfj-W_Q@mail.gmail.com>
* Andy Lutomirski <luto@amacapital.net> wrote:
> > These could still be open coded in an inlined fashion, like the scheduler usage.
>
> We could have a raw_rdmsr for those.
>
> OTOH, I'm still not 100% convinced that this warn-but-don't-die behavior is
> worth the effort. This isn't a frequent source of bugs to my knowledge, and we
> don't try to recover from incorrect cr writes, out-of-bounds MMIO, etc, so do we
> really gain much by rigging a recovery mechanism for rdmsr and wrmsr failures
> for code that doesn't use the _safe variants?
It's just the general principle really: don't crash the kernel on bootup. There's
few things more user hostile than that.
Also, this would maintain the status quo: since we now (accidentally) don't crash
the kernel on distro kernels (but silently and unsafely ignore the faulting
instruction), we should not regress that behavior (by adding the chance to crash
again), but improve upon it.
Thanks,
Ingo
next prev parent reply other threads:[~2015-10-01 7:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-21 0:02 [PATCH v2 0/2] x86/msr: MSR access failure changes Andy Lutomirski
2015-09-21 0:02 ` [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops Andy Lutomirski
2015-09-21 0:15 ` Linus Torvalds
2015-09-21 1:13 ` Andy Lutomirski
2015-09-21 8:46 ` Ingo Molnar
2015-09-21 12:27 ` Paolo Bonzini
2015-09-21 16:36 ` Linus Torvalds
2015-09-21 16:49 ` Arjan van de Ven
2015-09-21 17:27 ` Linus Torvalds
2015-09-21 17:43 ` Andy Lutomirski
2015-09-22 8:12 ` Paolo Bonzini
2015-09-21 18:16 ` Andy Lutomirski
2015-09-21 18:36 ` Borislav Petkov
2015-09-21 18:47 ` Linus Torvalds
2015-09-22 7:14 ` Ingo Molnar
2015-09-30 13:10 ` Peter Zijlstra
2015-09-30 14:01 ` Ingo Molnar
2015-09-30 18:04 ` Andy Lutomirski
2015-10-01 7:15 ` Ingo Molnar [this message]
2016-03-11 16:48 ` Andy Lutomirski
2016-03-12 16:02 ` Ingo Molnar
2015-09-30 18:32 ` H. Peter Anvin
2015-09-21 0:02 ` [PATCH v2 2/2] x86/msr: Set the return value to zero when native_rdmsr_safe fails 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=20151001071505.GA21542@gmail.com \
--to=mingo@kernel.org \
--cc=Xen-devel@lists.xen.org \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--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;
as well as URLs for NNTP newsgroup(s).