[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <847bx5peda.fsf@jogness.linutronix.de>
Date: Wed, 08 Oct 2025 18:12:25 +0206
From: John Ogness <john.ogness@...utronix.de>
To: Petr Mladek <pmladek@...e.com>, Andrew Murray
<amurray@...goodpenguin.co.uk>
Cc: Steven Rostedt <rostedt@...dmis.org>, Sergey Senozhatsky
<senozhatsky@...omium.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/3] printk: console_flush_one_record() code cleanup
On 2025-10-03, Petr Mladek <pmladek@...e.com> wrote:
> From 30f5302b11962f8ec961ca85419ed097a5b76502 Mon Sep 17 00:00:00 2001
> From: Petr Mladek <pmladek@...e.com>
> Date: Sat, 27 Sep 2025 23:05:36 +0100
> Subject: [PATCH 2/3] printk: console_flush_one_record() code cleanup
>
> console_flush_one_record() and console_flush_all() duplicate several
> checks. They both want to tell the caller that consoles are not
> longer usable in this context because it has lost the lock or
> the lock has to be reserved for the panic CPU.
>
> Remove the duplication by changing the semantic of the function
> console_flush_one_record() return value and parameters.
>
> The function will return true when it is able to do the job. It means
> that there is at least one usable console. And the flushing was
> not interrupted by a takeover or panic_on_other_cpu().
>
> Also replace the @any_usable parameter with @try_again. The @try_again
> parameter will be set to true when the function could do the job
> and at least one console made a progress.
>
> Motivation:
>
> The callers need to know when
>
> + they should continue flushing => @try_again
> + when the console is flushed => can_do_the_job(return) && !@..._again
> + when @next_seq is valid => same as flushed
> + when lost console_lock => @takeover
>
> The proposed change makes it clear when the function can do
> the job. It simplifies the answer for the other questions.
>
> Also the return value from console_flush_one_record() can
> be used as return value from console_flush_all().
>
> Signed-off-by: Petr Mladek <pmladek@...e.com>
Reviewed-by: John Ogness <john.ogness@...utronix.de>
Powered by blists - more mailing lists