From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753096AbbLJVQ1 (ORCPT ); Thu, 10 Dec 2015 16:16:27 -0500 Received: from www.linutronix.de ([62.245.132.108]:36861 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751227AbbLJVQ0 (ORCPT ); Thu, 10 Dec 2015 16:16:26 -0500 Date: Thu, 10 Dec 2015 22:15:35 +0100 (CET) From: Thomas Gleixner To: Andy Lutomirski cc: Jeff Merkey , LKML , Ingo Molnar , "H. Peter Anvin" , X86 ML , Peter Zijlstra , Andy Lutomirski , Masami Hiramatsu , Steven Rostedt , Borislav Petkov , Jiri Olsa Subject: Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is registeredy In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) 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,URIBL_BLOCKED=0.001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 10 Dec 2015, Andy Lutomirski wrote: > On Thu, Dec 10, 2015 at 12:49 PM, Thomas Gleixner wrote: > > On Thu, 10 Dec 2015, Andy Lutomirski wrote: > >> On brief inspection, this smells like a microcode bug. Can you send > >> /proc/cpuinfo output? > >> > >> If this is the issue, I'm not sure we want to be in the business of > >> working around localized microcode bugs and, if we do, then I think we > >> should explicitly detect the bug and log about it. > > > > I think we should handle such stuff gracefully. Yes, we should log it > > and we also should check what the contents of the debug registers are. > > > > If dr7 has a break point enabled w/o perf having one installed then we > > know that someone did a horrible hackery .... > > I mis-read this. I don't think this is the microcode bug. > > Do we know what the actual problem is? Jeff, how did you trigger this? > > If it's lazy DR switching (which I haven't looked at the details of), > then it seems that this could just be triggered by some unfortunate > combination of perf config and context switching). But, if so, then I > think that the proposed fix is wrong -- shouldn't we fix dr7 rather > than fudging RF to work around this instance of the problem? After > all, if we're hitting this condition in a tight userspace loop, we're > going to destroy performance unless we fix dr7. Right, if dr7 contains a valid breakpoint and perf does not have one installed then either that lazy DR stuff is flaky or someone else fiddled with dr7. In both cases we want to fix dr7 and yell about it. If we neither have a breakpoint nor dr7 has one enabled then its something spurious and we certainly want to set RF so the machine can make progress. Thanks, tglx