Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp3837154iog; Tue, 21 Jun 2022 07:00:29 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sF1KgPzBPg055EA7xl14WVFXMBLPU6iBB0CEpR79tct18unhcCz8dYL+Es9WNjg6K2qzRK X-Received: by 2002:a17:906:449:b0:711:c975:cfb8 with SMTP id e9-20020a170906044900b00711c975cfb8mr26793804eja.58.1655820029464; Tue, 21 Jun 2022 07:00:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655820029; cv=none; d=google.com; s=arc-20160816; b=eAggVm4ADQIp7epnJ2U1/QPGrFDd3L0e4f43mDaYLNRfOjPSbXSR8/JvyYkvX6N/Dd weJKK0pRo1YdJ4nHsD0wVq7imxtlcwaE+/IdSVQkEsdqlwBBqcS7+al70DmVSpquPYIE SkKQy2d102w0SmeRw+Lpp+Yn+oLarGqv94ozkPMvsFGphZgJvsJCNCsPf1SjHkk3Mc3M oZbBpFyz4uR/YUs8f4PApcVTAngLGb/nVh2xfP4i1W6hFE+nJJDlNIk8Ic3XOYmomLAB ivM0JWr8Hph4QRcyyW2wqPZN+GsTjS7bBttKgVfZ+DFRrBJpSfZGT16T0wCdqPdvUEuu bgFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=jvGgI6qCVd6nlUI3/RoXRoqsqujRz6BUFTJMj0MjmhI=; b=U5bJGpgWZWKFubWK/cZ4Rup/mpuxexesnZW5Xx8Nx3ohlvfh/KcgYuEGM4aCp2W0Ag 31lz7zViBoHeT885pxxqIPBp8xWaB1Rfz41mXDJDjsg87mJA06YE9aOMGRCTxe9mG5FS hGqdqLneWq5aYDamrhVJEe2rW/xt/JjHr+4Uhth736RsWNV4ellC8uyVrW2OQgBMPsPP /NIP1LpFbPTQkWSncV28k8/dAXnfOtOtCmxB5vIB1FgUeRZKvXn9q9gO6HkvXYd443vE 0ismspyGwvsbOErE0FXTczq+cX29JxdNHKgexuYLnp9fizE4JxZkHM4ESe0RDQjFK7hS tJSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=r4Wu8QcE; 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=QUARANTINE 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 di12-20020a170906730c00b006f3c67436e6si2970127ejc.890.2022.06.21.07.00.01; Tue, 21 Jun 2022 07:00:29 -0700 (PDT) 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=r4Wu8QcE; 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=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232569AbiFUNzk (ORCPT + 99 others); Tue, 21 Jun 2022 09:55:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229717AbiFUNzh (ORCPT ); Tue, 21 Jun 2022 09:55:37 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3CFF19C21 for ; Tue, 21 Jun 2022 06:55:36 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 9172521B85; Tue, 21 Jun 2022 13:55:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1655819735; 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=jvGgI6qCVd6nlUI3/RoXRoqsqujRz6BUFTJMj0MjmhI=; b=r4Wu8QcEySvMWz98zXQz+qyxxZmzO+/xkN6D9pFl+3V1b6D9PqbKu5tnaNmyfG9V0HrjDF 4MGKVXGMeW7eufqan2/OCvazAZSqaWs8NSrmYzhi6BP2R+tV7fFCciOkhcSAiF9K3FOSQm g3JaGToFgTfeoJN8iA9kqsRiBz78N88= Received: from suse.cz (pathway.suse.cz [10.100.12.24]) (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 F1C572C141; Tue, 21 Jun 2022 13:55:33 +0000 (UTC) Date: Tue, 21 Jun 2022 15:55:33 +0200 From: Petr Mladek To: Linus Torvalds Cc: Daniel Palmer , John Ogness , Marek =?iso-8859-1?Q?Beh=FAn?= , Linux Kernel Mailing List , Sergey Senozhatsky , Steven Rostedt , Andy Shevchenko , Rasmus Villemoes , Jan Kara , Peter Zijlstra Subject: Re: [PATCH v2] printk/console: Enable console kthreads only when there is no boot console left Message-ID: <20220621135533.GF7891@pathway.suse.cz> References: <20220621090900.GB7891@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,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 Tue 2022-06-21 07:45:09, Linus Torvalds wrote: > On Tue, Jun 21, 2022 at 6:42 AM Daniel Palmer wrote: > > > > The lockups on boot seem to be gone on my boards with this patch. > > Good. > > Petr, was this all the reports sorted out? Sounds like we can keep the > kernel thread model. Yes, it seems that we fixed all the reports when boot failed or the console was messed or silent. There is one more issue, see https://lore.kernel.org/r/YqyANveL50uxupfQ@zx2c4.com It is about synchronization between messages printed by userspace and kernel consoles. The synchronization was never guaranteed. I think that it is not an argument to remove the kthreads. They are really needed, especially for huge systems, noisy debugging, or RT where softlockups really hurts. My opinion is that we might easily support 3 printk modes, switched on the command line: 1. Use printk console kthreads when the system is normally running. It makes printk() predictable and safe. We do our best to switch to the direct mode when the kthreads are not reliable, for example, panic, suspend, reboot. IMHO, it should be default, especially for production systems. 2. Use an atomic console in fully synchronous mode. It is inspired by a patch from Peter Zijlstra. It calls the (serial) console directly from printk() and uses CPU-reentrant lock to serialize the messages between CPUs. AFAIK, Peter and some others use this approach to debug some nasty bugs in the scheduler, NMI, early boot when even the legacy code using console_lock() is not reliable enough. John Ogness is working on the atomic serial console. It would allow to integrate this mode a clean way. It is not usable for production because printk() might slow down the entire system. 3. Use the legacy code that tries to call consoles from printk() via console_trylock(). We need this code anyway for the early boot, suspend, reboot, panic. It would be used for debugging nasty bugs like the 2nd mode for system without serial console. It will be pretty hard to create lockless variant for more complicate consoles. I am not happy that we need more modes. But I think that they all have a good justification. Best Regards, Petr