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 S1757479AbcK3JIY (ORCPT <rfc822;w@1wt.eu>);
        Wed, 30 Nov 2016 04:08:24 -0500
Received: from mail.skyhub.de ([78.46.96.112]:33287 "EHLO mail.skyhub.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1757264AbcK3JID (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 30 Nov 2016 04:08:03 -0500
Date: Wed, 30 Nov 2016 10:07:58 +0100
From: Borislav Petkov <bp@alien8.de>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
        Steven Rostedt <rostedt@goodmis.org>, Jiri Olsa <jolsa@redhat.com>,
        "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: <20161130090758.afbfmuqeaiqbhvdp@pd.tnic>
References: <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>
 <alpine.DEB.2.20.1611291448080.4358@nanos>
 <20161130084828.7jsi6r6pxztj5dmz@pd.tnic>
 <alpine.DEB.2.20.1611300952380.3439@nanos>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.20.1611300952380.3439@nanos>
User-Agent: NeoMutt/20161014 (1.7.1)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Nov 30, 2016 at 09:54:58AM +0100, Thomas Gleixner wrote:
> Right, that's the safe bet. But I'm quite sure that the C1E crap only
> starts to work _after_ ACPI initialization.

Yap, I think it is an ACPI decision whether to enter C1E or not. And all
those boxes which are unaffected - they actually are but since the FW
doesn't enter C1E, they don't hit the bug.

> tick_force_broadcast() is irreversible

So if I let the cores in that small window use amd_e400_idle() and
then when I detect the machine doesn't enter C1E after all, I do
tick_broadcast_exit() on all cores in amd_e400_c1e_mask, then clear it
and free it, that would work?

Or do you see a better solution?

Thanks.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.