From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965648AbdLRRqZ (ORCPT ); Mon, 18 Dec 2017 12:46:25 -0500 Received: from mail.kernel.org ([198.145.29.99]:35218 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934637AbdLRRqQ (ORCPT ); Mon, 18 Dec 2017 12:46:16 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4981D20853 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Mon, 18 Dec 2017 12:46:13 -0500 From: Steven Rostedt To: Petr Mladek Cc: Sergey Senozhatsky , Tejun Heo , Sergey Senozhatsky , Jan Kara , Andrew Morton , Peter Zijlstra , Rafael Wysocki , Pavel Machek , Tetsuo Handa , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread Message-ID: <20171218124613.1df152da@gandalf.local.home> In-Reply-To: <20171218141353.6shpvcwth34k6dsi@pathway.suse.cz> References: <20171214181153.GZ3919388@devbig577.frc2.facebook.com> <20171215021024.GA11199@jagdpanzerIV> <20171214221831.3ead0298@vmware.local.home> <20171215050607.GC11199@jagdpanzerIV> <20171215083151.cu3xbdgmxqkszwso@pathway.suse.cz> <20171215084236.GE468@jagdpanzerIV> <20171215090801.eulx4pg54p667ya5@pathway.suse.cz> <20171218093405.GA31274@jagdpanzerIV> <20171218133101.ri55uwivhc5xwg5y@pathway.suse.cz> <20171218133948.GD31274@jagdpanzerIV> <20171218141353.6shpvcwth34k6dsi@pathway.suse.cz> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 18 Dec 2017 15:13:53 +0100 Petr Mladek wrote: > One question is if we really want to rely on offloading in > this case. What if this is printed to debug some stalled > system. Correct, and this is what I call when debugging hard lockups, and I do it from NMI. Which the new NMI code prevents all the data I want to print to come out to console. I had to create a really huge buffer to print it. show_state_filter() is not a normal printk() call. It is used for debugging. Not a very good example of issues that happen on production systems. If anything, this should be disabled on a production system. Let's just add my patch (I'll respin it if it needs it), and send it off into the wild. Let's see if there's still reports of issues, and then come back to solutions. Because, really, I'm still not convinced that there's anything out there that needs much more "fixing" of printk(). -- Steve