From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1756928AbcK2OEo (ORCPT <rfc822;w@1wt.eu>);
        Tue, 29 Nov 2016 09:04:44 -0500
Received: from mx1.redhat.com ([209.132.183.28]:41290 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1754945AbcK2OEf (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 29 Nov 2016 09:04:35 -0500
Date: Tue, 29 Nov 2016 15:04:31 +0100
From: Jiri Olsa <jolsa@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Steven Rostedt <rostedt@goodmis.org>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
        Josh Triplett <josh@joshtriplett.org>,
        Andi Kleen <andi@firstfloor.org>, Jan Stancek <jstancek@redhat.com>
Subject: Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!
Message-ID: <20161129140431.GB4520@krava>
References: <20161121005343.GB1891@krava>
 <20161121092850.GF3102@twins.programming.kicks-ass.net>
 <20161121093424.GA9814@krava>
 <20161121125830.GE3092@twins.programming.kicks-ass.net>
 <20161121091543.45f49945@gandalf.local.home>
 <20161121143716.GG3092@twins.programming.kicks-ass.net>
 <20161121153538.27wegzmdv3om52xq@pd.tnic>
 <20161121154104.GA3124@twins.programming.kicks-ass.net>
 <20161121160653.s4i3nua46rtpvj5l@pd.tnic>
 <20161129131649.hajagzcjfhn5cenp@pd.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161129131649.hajagzcjfhn5cenp@pd.tnic>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 29 Nov 2016 14:04:34 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Nov 29, 2016 at 02:16:49PM +0100, Borislav Petkov wrote:
> On Mon, Nov 21, 2016 at 05:06:54PM +0100, Borislav Petkov wrote:
> > IOW, what's the worst thing that can happen if we did this below?
> > 
> > We basically get rid of the detection and switch the timer to broadcast
> > mode immediately on the halting CPU.
> > 
> > amd_e400_idle() is behind an "if (cpu_has_bug(c, X86_BUG_AMD_APIC_C1E))"
> > check so it will run on the affected CPUs only...
> > 
> > Thoughts?
> 
> Actually, here's a better version. The E400 detection works only after
> ACPI has been enabled so we piggyback the end of acpi_init().
> 
> We don't need the MSR read now - we do
> 
> 	if (static_cpu_has_bug(X86_BUG_AMD_APIC_C1E))
> 
> on the idle path which is as fast as it gets.
> 
> Any complaints about this before I go and test it everywhere?
> 
> It builds and boots in my guest here ok, not that it means a whole lot.
> 
> The good news is, I have collected a fleet of boxes which all have that
> erratum so testing should be pretty reliable. Something that doesn't
> happen everytime!

+1 one test server over here.. will check ;-)

jirka