From: John Ogness <john.ogness@linutronix.de>
To: Petr Mladek <pmladek@suse.com>
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 v3 6/6] printk: introduce console_prepend_dropped() for dropped messages
Date: Tue, 03 Jan 2023 14:50:23 +0106 [thread overview]
Message-ID: <87o7rfd96w.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <Y7QtusGlIX3AU+TN@alley>
On 2023-01-03, Petr Mladek <pmladek@suse.com> wrote:
> Well, what about making sure that something more useful is always
> printed. For example:
>
> /*
> * Make sure outbuf is sufficiently large before prepending.
> * Keep at least the prefix when the message has to be truncated.
> * It is a rather theoretical problem when someone tries to
> * use a minimalist buffer.
> */
> if (WARN_ON_ONCE(len + PREFIX_MAX + 1 >= outbuf_sz))
> return;
I am fine with this. We won't see this warning anyway. Few lines would
ever be printed correctly if anyone ever tries to use a buffer so small.
> If we want to use this way. It would probably make sense to
> rename PREFIX_MAX to CONSOLE_PREFIX_MAX.
Actually, I would like to rename all of those limit macros to something
that makes more sense for the new code base:
CONSOLE_EXT_LOG_MAX -> CONSOLE_MESSAGE_MAX
CONSOLE_LOG_MAX -> SYSLOG_MESSAGE_MAX
LOG_LINE_MAX -> PRINTK_RECORD_MAX
PREFIX_MAX -> CONSOLE_PREFIX_MAX
I have a patch to do this ready, but I did not want to post it until we
are finished with the thread/atomic work.
John
next prev parent reply other threads:[~2023-01-03 13:45 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-21 20:26 [PATCH printk v3 0/6] printk: cleanup buffer handling John Ogness
2022-12-21 20:26 ` [PATCH printk v3 1/6] printk: move size limit macros into internal.h John Ogness
2023-01-02 14:06 ` Petr Mladek
2022-12-21 20:27 ` [PATCH printk v3 2/6] console: Use BIT() macros for @flags values John Ogness
2022-12-21 20:27 ` [PATCH printk v3 3/6] console: Document struct console John Ogness
2022-12-21 20:27 ` [PATCH printk v3 4/6] printk: introduce struct console_buffers John Ogness
2023-01-02 15:15 ` Petr Mladek
2023-01-03 10:04 ` John Ogness
2022-12-21 20:27 ` [PATCH printk v3 5/6] printk: introduce console_get_next_message() and console_message John Ogness
2022-12-22 15:41 ` John Ogness
2023-01-03 14:04 ` Petr Mladek
2023-01-03 14:57 ` John Ogness
2023-01-03 15:55 ` Petr Mladek
2023-01-04 10:26 ` John Ogness
2023-01-04 10:42 ` Petr Mladek
2023-01-02 15:52 ` Petr Mladek
2023-01-03 15:41 ` John Ogness
2023-01-03 10:02 ` John Ogness
2023-01-03 14:05 ` Petr Mladek
2022-12-21 20:27 ` [PATCH printk v3 6/6] printk: introduce console_prepend_dropped() for dropped messages John Ogness
2023-01-02 16:19 ` Petr Mladek
2023-01-03 10:20 ` John Ogness
2023-01-03 13:29 ` Petr Mladek
2023-01-03 13:44 ` John Ogness [this message]
2023-01-03 14:16 ` Petr Mladek
2023-01-03 15:00 ` John Ogness
2023-01-03 16:13 ` Petr Mladek
2023-01-04 9:06 ` John Ogness
2023-01-04 10:33 ` Petr Mladek
2023-01-05 13:14 ` kernel test robot
2023-01-05 13:55 ` 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=87o7rfd96w.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--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.