public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Ogness <john.ogness@linutronix.de>
To: Andrew Murray <amurray@thegoodpenguin.co.uk>
Cc: Petr Mladek <pmladek@suse.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] printk: console_flush_one_record() code cleanup
Date: Wed, 01 Oct 2025 11:59:10 +0206	[thread overview]
Message-ID: <84seg3gd89.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <CALqELGwd1CiRAYNBVWsrgb5T3eJ9ugP+0wG2WKZGvSfowqgaaQ@mail.gmail.com>

On 2025-09-30, Andrew Murray <amurray@thegoodpenguin.co.uk> wrote:
>> On 2025-09-27, Andrew Murray <amurray@thegoodpenguin.co.uk> wrote:
>> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> > index 060d4919de320fe21fd7aca73ba497e27c4ff334..e2c1cacdb4164489c60fe38f1e2837eb838107d6 100644
>> > --- a/kernel/printk/printk.c
>> > +++ b/kernel/printk/printk.c
>> > @@ -3193,6 +3194,7 @@ static bool console_flush_one_record(bool do_cond_resched, u64 *next_seq, bool *
>> >       bool any_progress;
>> >       int cookie;
>> >
>> > +     *any_usable = false;
>>
>> Since it is expected that @next_seq and @handover are initialized by
>> their callers (if their callers are interested in the values), then I
>> would expect @any_usable to be initialized by the
>> caller. console_flush_one_record() never reads this variable.
>
> Yes, that's correct. Perhaps the comments for the parameters should
> indicate otherwise?

They should clarify. For example, @next_seq is "valid only when this
function returns true" but @handover validitiy is not specified and is
also not related to the return value.

I would like to see the helper function provide clear usage. If the
caller is expected to initialize the parameters (which IMHO it should be
the case for all of the pointer parameters), then that should be
specified.

>> > @@ -3280,21 +3284,16 @@ static bool console_flush_one_record(bool do_cond_resched, u64 *next_seq, bool *
>> >   */
>> >  static bool console_flush_all(bool do_cond_resched, u64 *next_seq, bool *handover)
>> >  {
>> > -     bool any_usable = false;
>> > +     bool any_usable;
>>
>> Since console_flush_all() does read @any_usable, I would expect it to
>> initialize @any_usable. So I would not remove this definition initialization.
>
> Prior to this series, console_flush_all would set any_usable to false.
> It would be set to true if at any point a usable console is found,
> that value would be returned, or otherwise false if handover or panic.
> When the first patch split out this function, any_usable was kept as
> it was, leading to any_usable being true, even if a handover or panic
> had happened (hence additional checks needed, which are removed in
> this patch).
>
> By setting any_usable at the start of flush_one_record, it allows for
> any_usable to revert back to false, in the case where a once usable
> console is no longer usable. Thus representing the situation for the
> last record printed. It also makes console_flush_one_record easier to
> understand, as the any_usable flag will always be set, rather than
> only changing from false to true.

OK. But then just have console_flush_all() set @any_usable in the loop:

static bool console_flush_all(bool do_cond_resched, u64 *next_seq, bool *handover)
{
	bool any_progress;
	bool any_usable;

	*next_seq = 0;
	*handover = false;

	do {
		any_usable = false;
		any_progress = console_flush_one_record(do_cond_resched, next_seq,
							handover, &any_usable);
	} while (any_progress);

	return any_usable;
}

> Alternatively, it may be possible for console_flush_one_record to
> return any_usable, thus dropping it as an argument and removing the
> return of any_progress. Instead the caller could keep calling
> console_flush_one_record until it returns false or until next_seq
> stops increasing? Thus semantically, the return value of
> console_flush_one_record tells you that nothing bad happened and you
> can call it again, and the benefit of calling it again depends on if
> progress is being made (as determined by the caller through the
> existing seq argument).

Sorry, I could not follow how this would work. It sounds like a
simplification. If you can make it work, go for it.

John

  reply	other threads:[~2025-10-01  9:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-27 22:05 [PATCH v2 0/3] printk: Release console_lock between printing records in legacy thread Andrew Murray
2025-09-27 22:05 ` [PATCH v2 1/3] printk: Introduce console_flush_one_record Andrew Murray
2025-09-30 12:54   ` John Ogness
2025-09-30 13:21     ` Andrew Murray
2025-10-03 13:29   ` Petr Mladek
2025-09-27 22:05 ` [PATCH v2 2/3] printk: console_flush_one_record() code cleanup Andrew Murray
2025-09-30 12:59   ` John Ogness
2025-09-30 15:14     ` Andrew Murray
2025-10-01  9:53       ` John Ogness [this message]
2025-10-01 16:26         ` Andrew Murray
2025-10-02 10:10           ` Petr Mladek
2025-10-03 16:19             ` Petr Mladek
2025-10-08 16:06               ` John Ogness
2025-09-27 22:05 ` [PATCH v2 3/3] printk: Use console_flush_one_record for legacy printer kthread Andrew Murray
2025-09-30 13:03   ` John Ogness
2025-09-30 13:20     ` Andrew Murray
2025-10-03 16:26   ` Petr Mladek
2025-10-08 16:15     ` John Ogness

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84seg3gd89.fsf@jogness.linutronix.de \
    --to=john.ogness@linutronix.de \
    --cc=amurray@thegoodpenguin.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox