Date: Sat, 12 Mar 2016 17:02:42 +0100
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
Message-ID: <20160312160241.GA11531@gmail.com>
References: <130a3b7ef4788baae3a6fe71293ab17442bc9a0a.1442793572.git.luto@kernel.org>
 <CA+55aFy4Chd-PJvxGne=TztPsvFqUG07Ht8mtc4+0oGNZNDOyw@mail.gmail.com>
 <CALCETrXqsKcqzfqMO2ctOJJ4X8Kb6vvoUpVDir9F2-a3XwK23w@mail.gmail.com>
 <20150921084642.GA30984@gmail.com>
 <CA+55aFzKCi6pf0RP8HjDQYDsms6reB5AihuCAHEkVJtoOHk_Yw@mail.gmail.com>
 <20150930131002.GK2881@worktop.programming.kicks-ass.net>
 <20150930140122.GB3285@gmail.com>
 <CALCETrVMV2_3ywQ_t+0rsqzxMm6D9PvDEmOdrie67rRzfj-W_Q@mail.gmail.com>
 <20151001071505.GA21542@gmail.com>
 <CALCETrUFakwGL9zpj9TwKX9KbG9czq8fpEViU3nWaCvnpGurew@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALCETrUFakwGL9zpj9TwKX9KbG9czq8fpEViU3nWaCvnpGurew@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1549
Lines: 37


* Andy Lutomirski <luto@amacapital.net> wrote:

> On Thu, Oct 1, 2015 at 12:15 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * 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.
> 
> Just a heads up: the extable improvements in tip:ras/core make it
> straightforward to get the best of all worlds: explicit failure
> handling (written in C!), no fast path overhead whatsoever, and no new
> garbage in the exception handlers.

I _knew_ I should have merged them into tip:x86/mm, not tip:ras/core ;-)

I had a quick look at your new MSR series and I'm very happy with that direction!

Thanks,

	Ingo