Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp1347285pxb; Fri, 18 Feb 2022 06:05:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJy7dmBWQx9Lyy8Kssvb9XTbtSpjgbtx/r8QuGBvjcTNicvbAkyvwVLp057r/uL1fHEXwWKJ X-Received: by 2002:a63:4d02:0:b0:372:9a57:5873 with SMTP id a2-20020a634d02000000b003729a575873mr6407922pgb.503.1645193127611; Fri, 18 Feb 2022 06:05:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645193127; cv=none; d=google.com; s=arc-20160816; b=0OtQiEMuWfNrP7W7LpKmmCeh9uJy6YKMpx/GpHmcYzbxRpR5jw0K1YMiOzB2HrkIFM IK0GwDqTpRu/1Ad6R0LDPpnN7OeImoD7foMBYvywLlJShAslM+2tjidrM0wKLoU1K/MG 0Vy302MdK3VhUHBUrfWiDOJdascEQwvDT0lIgybTan93ImbsCPTEgPV8Sppbf7x7Yw2D myv6OAXwvpYslTxqsrZnO5aoN3YyQiLWbM8uhMcEqysFediEeCRZadNC8tOGazs5XteB 6V4jF2s329UcTBLLEjyC+gT3NPzJivlAmO8ZuxOX1LSCpH0rFalQQjRtQT8o7UeefHcA JQtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=S4IZUhjyn1DHXSRgbOfbbnOadkzvb3ybW3FaLTMPVUc=; b=fMzIbN6LYf5763V/VC6kPhXj8rEGrz6KITldMQL7hWu87iir/C+S0C4gGLGLR1pe5B ZhEVG9DkvOo45giK3M6jXi1HaxJWcRINvoali+FPQrsyT/ChtkqnZ9Frrhb5m/C3bcqZ 1k6cT3hsNTT8TJ7lH03POJMoiS1A0ECkolKNSrl8N1N3dDsXx8GGPjRregIn7/4xQ9vy eXcbpcapdBb0TuE9VcyeO2zVsVl/xCFDZxK3me6w5Od+uM+JbFmjZX6RlccTFGKrBifx A+/zdigGxCe4zqVpgwqdA++u0fOL/WZqnflBrYxqcA+v7gKV1e+RbUwUK8jehSSG51Ll hbew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=DJo7j+eY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r24si4049942pgm.83.2022.02.18.06.04.55; Fri, 18 Feb 2022 06:05:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=DJo7j+eY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235100AbiBRMwx (ORCPT + 99 others); Fri, 18 Feb 2022 07:52:53 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:44764 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233102AbiBRMwr (ORCPT ); Fri, 18 Feb 2022 07:52:47 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9631129C119; Fri, 18 Feb 2022 04:52:30 -0800 (PST) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id CA9FE1F37E; Fri, 18 Feb 2022 12:52:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1645188748; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=S4IZUhjyn1DHXSRgbOfbbnOadkzvb3ybW3FaLTMPVUc=; b=DJo7j+eYEv6tDBrb+EJzaquW1aG6cQiFQXpw2eWsXi+7nkwUyADoCIi63VeIKPocuNHeHz 7uOoFs+vzzzRJhEvVQruWz6C8JNytup98z76EcPo/ugXo0g37RI7NjBz3fakVv4tTf2/wX rV5gImHMPmSCAaGf3LeBKCZqaQ3PExY= Received: from suse.cz (unknown [10.100.216.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id B43CFA3B85; Fri, 18 Feb 2022 12:52:26 +0000 (UTC) Date: Fri, 18 Feb 2022 13:52:23 +0100 From: Petr Mladek To: David Laight Cc: John Ogness , Sergey Senozhatsky , Steven Rostedt , Thomas Gleixner , "linux-kernel@vger.kernel.org" , Greg Kroah-Hartman , Jiri Slaby , "Paul E. McKenney" , Josh Triplett , Mathieu Desnoyers , Lai Jiangshan , Joel Fernandes , Corey Minyard , Kees Cook , Christian Brauner , Daniel Bristot de Oliveira , Andy Shevchenko , Peter Zijlstra , Daniel Lezcano , "Rafael J. Wysocki" , Mark Brown , Josef Bacik , "Eric W. Biederman" , Shawn Guo , Matti Vaittinen , Andrew Morton , Wang Qing , Tejun Heo , Randy Dunlap , Alexander Potapenko , Stephen Boyd , Nicholas Piggin , "rcu@vger.kernel.org" Subject: Re: [PATCH printk v1 09/13] printk: add functions to allow direct printing Message-ID: References: <20220207194323.273637-1-john.ogness@linutronix.de> <20220207194323.273637-10-john.ogness@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 2022-02-18 09:00:46, David Laight wrote: > > On Mon 2022-02-07 20:49:19, John Ogness wrote: > > > Once kthread printing is introduced, console printing will no longer > > > occur in the context of the printk caller. However, there are some > > > special contexts where it is desirable for the printk caller to > > > directly print out kernel messages. > > Yes - most of them. > > It is going to be pretty impossible to do 'hard' kernel debugging > if printk get deferred. What do you exactly mean by 'hard' kernel debugging, please? What exactly won't be possible, please? It is really important to talk about real scenarios because we do our best to address them. This patchset disables the deferred console handling in several situations, especially during panic, reboot, kexec. The consoles are flushed during suspend, etc. The patchset solves real problems, soft and live-lockups and even deadlocks. It will actually allow debugging when too many messages caused softlockups and the system died. I saw it many times during boot of systems with many network interfaces or disks. Backtraces from all CPUs and processes, detailed Oops reports, and similar extensive output was able to kill the system. In each case, the legacy "direct" mode will still be around. > Typically there already is a deferral method. > The prints aren't done by the kernel, but by syslogd. syslogd helps only when userspace works and the messages can be stored on a filesystems. And it is perfectly fine and much more safe to defer consoles most of the time. I have seen many reports where consoles put the system into knees. And sometime printk() was the root of all problems. Best Regards, Petr