Received-SPF: pass (google.com: domain of linux-kernel+bounces-56795-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Wed, 7 Feb 2024 17:53:23 +0100
From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	Mukesh Ojha <quic_mojha@quicinc.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Arnd Bergmann <arnd@arndb.de>, Uros Bizjak <ubizjak@gmail.com>,
	"Guilherme G. Piccoli" <gpiccoli@igalia.com>
Subject: Re: [PATCH printk v4 00/14] fix console flushing
Message-ID: <ZcO1g0dDmdJMefnC@alley>
References: <20240207134103.1357162-1-john.ogness@linutronix.de>
 <ZcOtXKtHuVUTQNRN@alley>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZcOtXKtHuVUTQNRN@alley>

On Wed 2024-02-07 17:18:38, Petr Mladek wrote:
> On Wed 2024-02-07 14:46:49, John Ogness wrote:
> > Hi,
> > 
> > While testing various flushing scenarios, I stumbled on a few
> > issues that cause console flushing to fail. While at LPC2023 in
> > Richmond, I sat down with Petr Mladek and we reviewed the
> > v2 [0] series. This series is the result of that offline
> > discussion. v3 is here [1].
> > 
> > This series addresses the following issues:
> > 
> > 1. The prb_next_seq() optimization caused inconsistent return
> >    values. Fix prb_next_seq() to the originally intended
> >    behavior but keep an optimization.
> > 
> > 2. pr_flush() might not wait until the most recently stored
> >    printk() message if non-finalized records precede it. Fix
> >    pr_flush() to wait for all records to print that are at
> >    least reserved at the time of the call.
> > 
> > 3. In panic, the panic messages will not print if non-finalized
> >    records precede them. Add a special condition so that
> >    readers on the panic CPU will drop records that are not in
> >    a consistent state.
> > 
> > 4. It is possible (and easy to reproduce) a scenario where the
> >    console on the panic CPU hands over to a waiter of a stopped
> >    CPU. Do not use the handover feature in panic.
> > 
> > 5. If messages are being dropped during panic, non-panic CPUs
> >    are silenced. But by then it is already too late and most
> >    likely the panic messages have been dropped. Change the
> >    non-panic CPU silencing logic to _immediately_ silence
> >    non-panic CPUs during panic. This also leads to clean panic
> >    output when many CPUs are blasting the kernel log.
> > 
> > 6. If a panic occurs in a context where printk() calls defer
> >    printing (NMI or printk_safe section), the printing of the
> >    final panic messages rely on irq_work. If that mechanism is
> >    not available, the final panic messages are not seen (even
> >    though they are finalized in the ringbuffer). Add one last
> >    explicit flush after all printk() calls are finished to
> >    ensure all available messages in the kernel log are printed.
> > 
> > 7. When dumping the stacktrace from panic(), do not use the
> >    printk_cpu_sync because it can deadlock if another CPU holds
> >    and is unable to release the printk_cpu_sync.
> > 
> > This series also performs some minor cleanups to remove open
> > coded checks about the panic context and improve documentation
> > language regarding data-less records.
> > 
> > Because of multiple refactoring done in recent history, it
> > would be helpful to provide the LTS maintainers with the proper
> > backported patches. I am happy to do this.
> 
> The series seems to be ready linux-next from my POV. I am going
> to push it there so that it gets as much testing before
> the merge window as possible.

JFYI, it has been committed into printk/linux.git,
branch rework/console-flushing-fixes.

Let's keep our fingers crossed.

Best Regards,
Petr