Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp829326img; Thu, 21 Mar 2019 09:46:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqxkQJlw0QU1bnpCye25ilLDApCRisi6AE4fXNMOUJyv3NC6ZQv9bnFRPNIWc2sCc5wlblSA X-Received: by 2002:a63:5159:: with SMTP id r25mr4285498pgl.112.1553186813074; Thu, 21 Mar 2019 09:46:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553186813; cv=none; d=google.com; s=arc-20160816; b=vQ/9nAy2FqG39NY6L5TkF/5x5v5P9v4aSyOXYusCrRibbpd2cgICeE1ocadXXjys7A eFyicf10e8cZANFa7qXRPCfVYy2BYZ0TC/Ne0A+v0swCnk5he2KqGZjoj75QDfV+BxfE VDMzrKNr3MZ3kfRkVbcTsmhT+0PDPy6W7solrM3Q5yopR5uqstqANFc6QwwsRGWmDU/f ckYi2dCfr1M1pCfGVDF52tjLPdYu/K7rsk+3mCpOq6MPQG16F1Vl4bAPzLCTmpvG1cCe TYj675DSRXJxqY4Vf8yJRUVcMeXNpnY0wH0tg7nEjsipZHO2haeCBwaHIdKIfK1N8c2F D9kQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=FodiUfi9x8lOonSXqyMvHlQRRrBZ+Ya0Of2FoTD/lLI=; b=fiIPdcE7wsqsy/lQGFItfP/+Aiv8Mvevw5VO5XEm4OA7Slp0bIpgZIodfh/ZDxJddr zqqboa0HbSJER5OCxzlFP9S8l7J0AfXNXl+Jne43BU7H0aatKGaORpyLLYrQ9gOdvk1m O9uymAQFE0lDPxSazUlbgeg70TzUQqaEFkPZ3YhtVfvqQuO+bK4wILZGqGEe9WpEzatT RKUk/ByduLt5PhSlEr8rxJesugDMX/ArnaDme3ncyjX6Iy22KXh2/8ve7RErXSCLqeqd II7JEUJTWoiJd4ElM7tJxoA8wQR8uuyXZ06ABy5yANRn1c/7d0FD+3INKdtlvE+DTDPz 2dbg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n8si4750289plk.316.2019.03.21.09.46.34; Thu, 21 Mar 2019 09:46:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728513AbfCUQpt (ORCPT + 99 others); Thu, 21 Mar 2019 12:45:49 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:38775 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728157AbfCUQpt (ORCPT ); Thu, 21 Mar 2019 12:45:49 -0400 Received: from p5492e2fc.dip0.t-ipconnect.de ([84.146.226.252] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1h70p3-0001K5-St; Thu, 21 Mar 2019 17:45:42 +0100 Date: Thu, 21 Mar 2019 17:45:41 +0100 (CET) From: Thomas Gleixner To: Peter Zijlstra cc: Stephane Eranian , Ingo Molnar , Jiri Olsa , LKML , tonyj@suse.com, nelson.dsouza@intel.com Subject: Re: [PATCH 1/8] perf/x86/intel: Fix memory corruption In-Reply-To: <20190321123849.GN6521@hirez.programming.kicks-ass.net> Message-ID: References: <20190314130113.919278615@infradead.org> <20190314130705.441549378@infradead.org> <20190319110549.GC5996@hirez.programming.kicks-ass.net> <20190319182041.GO5996@hirez.programming.kicks-ass.net> <20190320222220.GA2490@worktop.programming.kicks-ass.net> <20190321123849.GN6521@hirez.programming.kicks-ass.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 21 Mar 2019, Peter Zijlstra wrote: > Subject: perf/x86/intel: Initialize TFA MSR > > Stephane reported that we don't initialize the TFA MSR, which could lead > to trouble if the RESET value is not 0 or on kexec. That sentence doesn't parse. Stephane reported that the TFA MSR is not initialized by the kernel, but the TFA bit could set by firmware or as a leftover from a kexec, which makes the state inconsistent. > Reported-by: Stephane Eranian > Signed-off-by: Peter Zijlstra (Intel) > --- > arch/x86/events/intel/core.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c > index 8baa441d8000..2d3caf2d1384 100644 > --- a/arch/x86/events/intel/core.c > +++ b/arch/x86/events/intel/core.c > @@ -3575,6 +3575,12 @@ static void intel_pmu_cpu_starting(int cpu) > > cpuc->lbr_sel = NULL; > > + if (x86_pmu.flags & PMU_FL_TFA) { > + WARN_ON_ONCE(cpuc->tfa_shadow); Hmm. I wouldn't warn here as this is a legit state for kexec/kdump and I don't think we can figure out whether this comes directly from the firmware. Thanks, tglx