From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B470E92706 for ; Thu, 5 Oct 2023 14:37:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235365AbjJEOhS (ORCPT ); Thu, 5 Oct 2023 10:37:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235193AbjJEOfD (ORCPT ); Thu, 5 Oct 2023 10:35:03 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB8303698 for ; Thu, 5 Oct 2023 06:59:35 -0700 (PDT) From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1696514369; h=from:from:reply-to:subject:subject: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=HefGVIbKSQ3vy0UfHqATp/KOc0Tq42iQ8ydZMVaCb8c=; b=2IOGzdwZ9qsltc3VzYE5j9y4RlFQIW+YWutgC088wz01n3Py2dlZKPMcULBCz3J8dnWdDm wmcHGtou++xiMX0rRUTH+LFd91FQB4XwfLVj8EJyXCytcjTu8G7PvpiFewq1Yy5gWF5FS3 hDwGDcg4x/ceGWomUCNzbP7mMWS/dusbAJWSM/0cx9iqOYVNDPQQCPwdjhkwsEWt4LVWZp 0IdB+KBN+ECync+My5OTb4iWCReS51X1RDfyM1uDfNQtSUqhOdeZR3OLAkv+mCqaYe+Vta Vf4t+yUMXd0M80tFMnDDHTYOw4pXsW0ToClQygy0ZnCnK9QFRiLe6PkZt0VceQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1696514369; h=from:from:reply-to:subject:subject: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=HefGVIbKSQ3vy0UfHqATp/KOc0Tq42iQ8ydZMVaCb8c=; b=1/71++pw1ukYqHa6TixEjX6KNLofwMzjRdS+fyU0Bi3JqPyvnDfRRZ0vOZFf/XTaa3gQPH J/R2VRFsS3JWZ5CA== To: Petr Mladek Cc: Sergey Senozhatsky , Steven Rostedt , Thomas Gleixner , linux-kernel@vger.kernel.org Subject: Re: [PATCH printk v2 06/11] printk: nbcon: Wire up nbcon console atomic flushing In-Reply-To: References: <20230919230856.661435-1-john.ogness@linutronix.de> <20230919230856.661435-7-john.ogness@linutronix.de> <87a5tabchs.fsf@jogness.linutronix.de> Date: Thu, 05 Oct 2023 16:05:27 +0206 Message-ID: <87edi9tbk0.fsf@jogness.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023-09-26, Petr Mladek wrote: > Anyway, the proposed behavior (agreed on LPC2022) seems > to contradict the original plan from LPC 2019, see > https://lore.kernel.org/all/87k1acz5rx.fsf@linutronix.de/ > Namely: > > --- cut --- > 3. Rather than defining emergency _messages_, we define an emergency > _state_ where the kernel wants to flush the messages immediately before > dying. Unlike oops_in_progress, this state will not be visible to > anything outside of the printk infrastructure. > > 4. When in emergency state, the kernel will use a new console callback > write_atomic() to flush the messages in whatever context the CPU is in > at that moment. Only consoles that implement the NMI-safe write_atomic() > will be able to flush in this state. > --- cut --- > > We wanted to flush it ASAP. In 2019 we didn't have all the code yet. Yes, we assumed that flushing each individual printk() call would be how to do it. But in 2022, during a live demo with real code, we saw that it was a bad idea. I disagree that the 2022 decisions are contradicting the 2019 decisions. We have added more details because now we have a real implementation. v2 establishes an emergency state before dying. v2 flushes the messages safely before dying (and unsafely _immediately_ before dying). v2 flushes the messages in whatever context the CPU is in. v2 uses write_atomic() to perform the flush. John