Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp6370592ybe; Wed, 18 Sep 2019 02:17:46 -0700 (PDT) X-Google-Smtp-Source: APXvYqz0dJX0qpksyJPX6BaWvLZ4+1/Loc4hYDJ7Hgz4TB105OUhFTmNIQZpX5fNO3IMZU18Ptu8 X-Received: by 2002:aa7:c1d4:: with SMTP id d20mr8932427edp.223.1568798266296; Wed, 18 Sep 2019 02:17:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568798266; cv=none; d=google.com; s=arc-20160816; b=Ww06AC+bDRXYOkWBG7O4yjJ/tzvzte96FA21I65MIvnLkqf28fxSkb94hFTrDfaURc +P+dvy5/DtTG62FNK6CmR25ESAygLywNOnJtHYaDyiRIahYj4Vz4AR2wSY5ARy0CvCn+ k1t/ZFJs6MLElUUkNGUOTIxnbaFTnsc09PWX8C6VSVn782yYNiZDV/MeRd1+xE/yaEx0 KR5iDBGPn1Z69HnRJMRY9FdIx2zpAlLKnZF8eTx5ovY0WZdWAiSaZOS8Xj8h7xBqT+gb QTcITbhYrNaeQAzhrBLDoN2gJt4lU3SeFNlzdhViQeHlqvIYS5nkkuattSh/mvvGdB1J cqKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from; bh=WExPvDQl665Nq272rO1TtRfxlEyS877nWbiFVlmqEiY=; b=tTnRzZaFwTrMmuaKaqnKOxsvtYFjGimucFU+GEL2rwnQ0QzcqNpLN6SSLASsPiZ5pj o8WNCVwg7BFEww7ZyTAxVYnerbOkpYCdAjKZlD14GwWOR8EGTxOa38al5XbOc3uW+aIB T/3Qc6yIfSEM5Tgr222RTtQ8BgNLd34LuU5n1PnuUmC/o0wQLMUPKcUtQ7Ul3OXliXcX wIDA5Dat7OHIIhUTm6sveuaxCtR9EzPA7TDNiNPq3eOaMqP+eocIdFdBo1XLcXfrD9dH LV10vHaVFZIEvyZqdVT9Y+ls8lEK7VwoTCiSqmyP/iZHAM5OwQ6MG7fbTSJWtIDeUrHH OMIQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g18si2879533edq.209.2019.09.18.02.17.22; Wed, 18 Sep 2019 02:17:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727563AbfIRHmm (ORCPT + 99 others); Wed, 18 Sep 2019 03:42:42 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:45116 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726937AbfIRHmm (ORCPT ); Wed, 18 Sep 2019 03:42:42 -0400 Received: from localhost ([127.0.0.1] helo=vostro.local) by Galois.linutronix.de with esmtp (Exim 4.80) (envelope-from ) id 1iAUbk-00008R-D2; Wed, 18 Sep 2019 09:42:36 +0200 From: John Ogness To: Sergey Senozhatsky Cc: Steven Rostedt , Linus Torvalds , Thomas Gleixner , Peter Zijlstra , Petr Mladek , Andrea Parri , Sergey Senozhatsky , Brendan Higgins , Greg Kroah-Hartman , LKML , Theodore Ts'o , Paul Turner , Daniel Vetter , Prarit Bhargava Subject: Re: printk meeting at LPC References: <20190904123531.GA2369@hirez.programming.kicks-ass.net> <20190905130513.4fru6yvjx73pjx7p@pathway.suse.cz> <20190905143118.GP2349@hirez.programming.kicks-ass.net> <20190905121101.60c78422@oasis.local.home> <87k1acz5rx.fsf@linutronix.de> <20190918012546.GA12090@jagdpanzerIV> <20190917220849.17a1226a@oasis.local.home> <20190918023654.GB15380@jagdpanzerIV> <20190918051933.GA220683@jagdpanzerIV> Date: Wed, 18 Sep 2019 09:42:34 +0200 In-Reply-To: <20190918051933.GA220683@jagdpanzerIV> (Sergey Senozhatsky's message of "Wed, 18 Sep 2019 14:19:33 +0900") Message-ID: <87h85anj85.fsf@linutronix.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-09-18, Sergey Senozhatsky wrote: >> For instance, tty/sysrq must be able to switch printk emergency >> on/off. > > How did we come up to that _sync() printk() emergency mode (when we > make sure that there is no active printing kthread)? We had a number > of cases (complaints) of lost kernel messages. There are scenarios in > which we cannot offload to async preemptible printing kthread, because > current control path is, for instance, going to reboot the kernel. In > sync printk() mode we have some sort (!) of guarantees that when we do > > pr_emerg("Restarting system\n"); > kmsg_dump(KMSG_DUMP_RESTART); > machine_restart(cmd); > > pr_emerg("Restarting system\n") is going to flush logbuf before the > system will machine_restart(). Yes, this was why I asked Daniel how the bsod stuff will be implemented. We don't want a bsod just because we are restarting. Perhaps write_atomic() should also have a "reason" argument like kmsg_dump does. I will keep in touch with Daniel to make sure we are sync on this. > It's going to be a bit harder when we have per-console kthread. Each console has its own iterator. This iterators will need to advance, regardless if the message was printed via write() or write_atomic(). John Ogness