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
Subject: Re: [PATCH printk v4 5/8] printk: introduce printk_get_next_message() and printk_message
Date: Thu, 5 Jan 2023 16:24:55 +0100 [thread overview]
Message-ID: <Y7brx08wN+TE/YLN@alley> (raw)
In-Reply-To: <20230105103735.880956-6-john.ogness@linutronix.de>
On Thu 2023-01-05 11:43:32, John Ogness wrote:
> Code for performing the console output is intermixed with code that
> is formatting the output for that console. Introduce a new helper
> function printk_get_next_message() to handle the reading and
> formatting of the printk text. The helper does not require any
> locking so that in the future it can be used for other printing
> contexts as well.
>
> This also introduces a new struct printk_message to wrap the struct
> printk_buffers, adding metadata about its contents. This allows
> users of printk_get_next_message() to receive all relevant
> information about the message that was read and formatted.
>
> Why is struct printk_message a wrapper struct?
>
> It is intentional that a wrapper struct is introduced instead of
> adding the metadata directly to struct printk_buffers. The upcoming
> atomic consoles support multiple printing contexts per CPU. This
> means that while a CPU is formatting a message, it can be
> interrupted and the interrupting context may also format a (possibly
> different) message. Since the printk buffers are rather large,
> there will only be one struct printk_buffers per CPU and it must be
> shared by the possible contexts of that CPU.
>
> If the metadata was part of struct printk_buffers, interrupting
> contexts would clobber the metadata being prepared by the
> interrupted context. This could be handled by robustifying the
> message formatting functions to cope with metadata unexpectedly
> changing. However, this would require significant amounts of extra
> data copying, also adding significant complexity to the code.
>
> Instead, the metadata can live on the stack of the formatting
> context and the message formatting functions do not need to be
> concerned about the metadata changing underneath them.
>
> Note that the message formatting functions can handle unexpected
> text buffer changes. So it is perfectly OK if a shared text buffer
> is clobbered by an interrupting context. The atomic console
> implementation will recognize the interruption and avoid printing
> the (probably garbage) text buffer.
Great description!
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
next prev parent reply other threads:[~2023-01-05 15:25 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-05 10:37 [PATCH printk v4 0/8] printk: cleanup buffer handling John Ogness
2023-01-05 10:37 ` [PATCH printk v4 1/8] printk: move size limit macros into internal.h John Ogness
2023-01-05 14:48 ` Petr Mladek
2023-01-05 10:37 ` [PATCH printk v4 2/8] console: Use BIT() macros for @flags values John Ogness
2023-01-05 10:37 ` [PATCH printk v4 3/8] console: Document struct console John Ogness
2023-01-05 10:37 ` [PATCH printk v4 4/8] printk: introduce struct printk_buffers John Ogness
2023-01-05 15:06 ` Petr Mladek
2023-01-05 10:37 ` [PATCH printk v4 5/8] printk: introduce printk_get_next_message() and printk_message John Ogness
2023-01-05 15:24 ` Petr Mladek [this message]
2023-01-05 10:37 ` [PATCH printk v4 6/8] printk: introduce console_prepend_dropped() for dropped messages John Ogness
2023-01-05 16:17 ` Petr Mladek
2023-01-05 16:35 ` John Ogness
2023-01-06 9:34 ` Petr Mladek
2023-01-05 10:37 ` [PATCH printk v4 7/8] printk: use printk_buffers for devkmsg John Ogness
2023-01-05 12:14 ` John Ogness
2023-01-05 12:16 ` [PATCH printk v4 7/8 v2] " John Ogness
2023-01-06 10:39 ` Petr Mladek
2023-01-08 21:11 ` John Ogness
2023-01-05 10:37 ` [PATCH printk v4 8/8] printk: adjust string limit macros John Ogness
2023-01-06 11:11 ` Petr Mladek
2023-01-06 11:21 ` [PATCH printk v4 0/8] printk: cleanup buffer handling Petr Mladek
2023-01-07 8:18 ` 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=Y7brx08wN+TE/YLN@alley \
--to=pmladek@suse.com \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.