From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755768AbcCNSFP (ORCPT ); Mon, 14 Mar 2016 14:05:15 -0400 Received: from mail-ig0-f193.google.com ([209.85.213.193]:35896 "EHLO mail-ig0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752388AbcCNSFA (ORCPT ); Mon, 14 Mar 2016 14:05:00 -0400 MIME-Version: 1.0 In-Reply-To: References: <20160314120202.GD15800@pd.tnic> Date: Mon, 14 Mar 2016 11:04:59 -0700 X-Google-Sender-Auth: zXd9M3vt3v_rrbxnBJfsq-fZfUY Message-ID: Subject: Re: [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops From: Linus Torvalds To: Andy Lutomirski Cc: Paolo Bonzini , xen-devel , Arjan van de Ven , Borislav Petkov , X86 ML , Andrew Morton , KVM list , Andy Lutomirski , "linux-kernel@vger.kernel.org" , Peter Zijlstra Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 14, 2016 at 10:17 AM, Andy Lutomirski wrote: > > So yes, let's please warn. I'm okay with removing the panic_on_oops > thing though. (But if anyone suggests that we should stop OOPSing on > bad kernel page faults, I *will* fight back.) Bad kernel page faults are something completely different. They would be actual bugs regardless. The MSR thing has *often* been just silly "this CPU doesn't do that MSR". Generic bootup setup code etc that just didn't know or care about the particular badly documented rule for one particular random CPU version and stepping. In fact, when I say "often", I suspect I should really just say "always". I don't think we've ever found a case where oopsing would have been the right thing. But it has definitely caused lots of problems, especially in the early paths where your code doesn't even work right now. Now, when it comes to the warning, I guess I could live with it, but I think it's stupid to make this a low-level exception handler thing. So what I think should be done: - make sure that wr/rdmsr_safe() actually works during very early init. At some point it didn't. - get rid of the current wrmsr/rdmsr *entirely*. It's shit. - Add this wrapper: #define wrmsr(msr, low, high) \ WARN_ON_ONCE(wrmsr_safe(msr, low, high)) and be done with it. We could even decide to make that WARN_ON_ONCE() be something we could configure out, because it's really a debugging thing and isn't like it should be all that fatal. None of this insane complicated crap that buys us exactly *nothing*, and depends on fancy new exception handling support etc etc. So what's the downside to just doing this simple thing? Linus