From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934620AbbLPRuP (ORCPT ); Wed, 16 Dec 2015 12:50:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42201 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932664AbbLPRuJ (ORCPT ); Wed, 16 Dec 2015 12:50:09 -0500 Date: Wed, 16 Dec 2015 12:50:00 -0500 From: Don Zickus To: Jeff Merkey Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org, uobergfe@redhat.com, atomlin@redhat.com, cmetcalf@ezchip.com, fweisbec , tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, peterz@infradead.org, luto@kernel.org Subject: Re: [PATCH] Fix spurious hard lockup events while in debugger Message-ID: <20151216175000.GM60826@redhat.com> References: <20151215033045.GA14158@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 16, 2015 at 10:22:18AM -0700, Jeff Merkey wrote: > On 12/14/15, Jeff Merkey wrote: > > The current touch_nmi_watchdog() function in /kernel/watchdog.c does > > not always catch all cases when a processor is spinning in the nmi > > handler inside either KGDB, KDB, or MDB, in particular, the case where > > a processor is being held by a debugger inside an int1 handler. > > > > The hrtimer_interrupts_saved count can still end up matching the > > hrtime value in some cases, resulting in the hard lockup detector > > tagging processors inside a debugger and executing a panic. > > > > The patch below corrects this problem. I did not add this to > > the touch_nmi_function directly becuase of possible affects on > > timing issues since the function is widely used by drivers and > > modules. > > > > I have tested this patch and it fixes the problem for kernel debuggers > > stopping errant hard lockup events when processors are spinning inside > > the debugger. > > > > Signed-off-by: Jeff Merkey > > --- > > kernel/watchdog.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/kernel/watchdog.c b/kernel/watchdog.c > > index 18f34cf..b682aab 100644 > > --- a/kernel/watchdog.c > > +++ b/kernel/watchdog.c > > @@ -283,6 +283,13 @@ static bool is_hardlockup(void) > > __this_cpu_write(hrtimer_interrupts_saved, hrint); > > return false; > > } > > + > > +void touch_hardlockup_watchdog(void) > > +{ > > + __this_cpu_write(hrtimer_interrupts_saved, 0); > > +} > > +EXPORT_SYMBOL_GPL(touch_hardlockup_watchdog); > > + > > #endif > > > > static int is_softlockup(unsigned long touch_ts) > > -- > > 1.8.3.1 > > > > > > I got to the bottom of it. It's related to the hardware I am using. > One of the processors is faulting and hanging due to an existing bug > in the hw_breakpoint handler not setting the resume flag (I have > previously reported it and submitted a patch). This breaks your code, > but there's nothing you can do about it. > > There is a severe bug in hw_breakpoint.c that causes int1 recursion > and this whole "lazy debug register switching" nonsense does not work > properly. I am probably the first person to actually test this code > path robustly. I applied the patch that fixes this bug in > hw_breakpoint.c and the problem with your code firing off and ignoring > the touch flag > went away. Ah, good to know. Thanks! I'll drop this patch then. Cheers, Don