From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932319AbeAWVL7 (ORCPT ); Tue, 23 Jan 2018 16:11:59 -0500 Received: from mail-qt0-f177.google.com ([209.85.216.177]:33098 "EHLO mail-qt0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932146AbeAWVL6 (ORCPT ); Tue, 23 Jan 2018 16:11:58 -0500 X-Google-Smtp-Source: AH8x227nBLoMPl5CcUVXXaswRzNzy7gqLtCDqHQ2OSWXQB9yp47CCRMW65FUc1GUuDlnVHO3GlZPbg== Date: Tue, 23 Jan 2018 13:11:54 -0800 From: Tejun Heo To: Steven Rostedt Cc: Rik van Riel , Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, kernel-team@fb.com, Sergey Senozhatsky , Petr Mladek Subject: Re: [PATCH] lockdep: Avoid triggering hardlockup from debug_show_all_locks() Message-ID: <20180123211154.GI1771050@devbig577.frc2.facebook.com> References: <20180122220055.GB1771050@devbig577.frc2.facebook.com> <1516734237.31954.17.camel@fb.com> <20180123205706.GH1771050@devbig577.frc2.facebook.com> <20180123160054.325ff326@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180123160054.325ff326@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Steven. On Tue, Jan 23, 2018 at 04:00:54PM -0500, Steven Rostedt wrote: > On Tue, 23 Jan 2018 12:57:06 -0800 > Tejun Heo wrote: > > > Yeah, it's ridiculous how often printk ends up escalating otherwise > > recoverable situations into system crashes. I don't know what the > > right answer is. For spurious NMI hardlockups, maybe auditing debug > > paths and adding touch_nmi_watchdog() would be enough but that also is > > a pretty leaky approach. > > What about if every printk were to touch NMI watchdog? > > NMI watchdog is really there for when the system locks up. If the > system is locked up doing printk, at least we see what is happening, > and not a total freeze. Yeah, that would definitely be a solution. The downside is that when the system completely locks up from printk storm while holding critical locks (say, tasklist_lock), the watchdog won't be able to reset the system. I guess the judgement would depend on what one expects of the NMI watchdog, but I personally would be happier with printk touching NMI automatically. Thanks. -- tejun