From: John Ogness <john.ogness@linutronix.de>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org
Subject: Re: LINE_MAX: was: Re: [PATCH printk-rework 04/12] printk: define CONSOLE_LOG_MAX in printk.h
Date: Mon, 01 Feb 2021 09:30:10 +0106 [thread overview]
Message-ID: <87r1m02o2d.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <YBQtbKrdwUAZQB9v@alley>
On 2021-01-29, Petr Mladek <pmladek@suse.com> wrote:
>> diff --git a/include/linux/printk.h b/include/linux/printk.h
>> index fe7eb2351610..6d8f844bfdff 100644
>> --- a/include/linux/printk.h
>> +++ b/include/linux/printk.h
>> @@ -45,6 +45,7 @@ static inline const char *printk_skip_headers(const char *buffer)
>> }
>>
>> #define CONSOLE_EXT_LOG_MAX 8192
>> +#define CONSOLE_LOG_MAX 1024
>>
>> /* printk's without a loglevel use this.. */
>> #define MESSAGE_LOGLEVEL_DEFAULT CONFIG_MESSAGE_LOGLEVEL_DEFAULT
>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> index ec2174882b8e..5faf9c0db171 100644
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -410,7 +410,7 @@ static u64 clear_seq;
>> #else
>> #define PREFIX_MAX 32
>> #endif
>> -#define LOG_LINE_MAX (1024 - PREFIX_MAX)
>> +#define LOG_LINE_MAX (CONSOLE_LOG_MAX - PREFIX_MAX)
>
> CONSOLE_LOG_MAX defines size of buffers that are written by
> record_print_text(). We must make sure that all stored
> messages can actually get printed even with the trailing '\0'.
>
> We should limit the stored messages by:
>
> /*
> * Console log buffer needs extra space for the trailing '\0',
> * see reccord_print_text().
> */
> #define LOG_LINE_MAX (CONSOLE_LOG_MAX - PREFIX_MAX - 1)
>
> It should not be a big problem. The PREFIX_MAX size has already
> increased in the patch, for example, because of the caller ID.
>
> Does it make sense, please?
If we want to make sure "all stored messages can actually get printed",
then CONSOLE_LOG_MAX needs to be set to:
PREFIX_MAX * LOG_LINE_MAX + 1
and we should be specifying LOG_LINE_MAX instead of
CONSOLE_LOG_MAX. record_print_text() adds up to PREFIX_MAX for every
'\n' in the message.
I was initially confused by this, which led to my patch [0] to fix
it. But then I realized that the buffer is way too small anyway. If we
want to fix the issue, then LOG_LINE_MAX needs to be much larger.
IMO it makes no sense to do the -1 change because the buffer is too
small anyway.
John Ogness
[0] https://lkml.kernel.org/r/20210120194106.26441-2-john.ogness@linutronix.de
next prev parent reply other threads:[~2021-02-01 8:25 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-26 21:15 [PATCH printk-rework 00/12] printk: remove logbuf_lock John Ogness
2021-01-26 21:15 ` [PATCH printk-rework 01/12] printk: kmsg_dump: remove unused fields John Ogness
2021-01-26 21:15 ` [PATCH printk-rework 02/12] printk: refactor kmsg_dump_get_buffer() John Ogness
2021-01-26 21:15 ` [PATCH printk-rework 03/12] printk: consolidate kmsg_dump_get_buffer/syslog_print_all code John Ogness
[not found] ` <YBQgTQYTA5p6Wgj6@alley>
2021-02-01 9:49 ` John Ogness
2021-02-02 12:31 ` Petr Mladek
2021-01-26 21:15 ` [PATCH printk-rework 04/12] printk: define CONSOLE_LOG_MAX in printk.h John Ogness
[not found] ` <YBQtbKrdwUAZQB9v@alley>
2021-02-01 8:24 ` John Ogness [this message]
2021-02-02 11:22 ` LINE_MAX: was: " Petr Mladek
2021-01-26 21:15 ` [PATCH printk-rework 05/12] printk: use seqcount_latch for clear_seq John Ogness
2021-01-26 21:15 ` [PATCH printk-rework 06/12] printk: use atomic64_t for devkmsg_user.seq John Ogness
2021-01-26 21:15 ` [PATCH printk-rework 07/12] printk: add syslog_lock John Ogness
2021-02-01 12:26 ` Petr Mladek
2021-02-01 13:11 ` John Ogness
2021-02-02 12:50 ` Petr Mladek
2021-01-26 21:15 ` [PATCH printk-rework 08/12] printk: introduce a kmsg_dump iterator John Ogness
2021-02-01 13:17 ` Petr Mladek
2021-02-01 13:32 ` John Ogness
2021-01-26 21:15 ` [PATCH printk-rework 09/12] um: synchronize kmsg_dumper John Ogness
2021-02-01 10:26 ` Petr Mladek
2021-02-01 14:15 ` Petr Mladek
2021-02-01 16:51 ` John Ogness
2021-02-01 16:54 ` Richard Weinberger
2021-02-01 20:25 ` John Ogness
2021-02-01 20:40 ` Richard Weinberger
2021-02-02 13:26 ` Petr Mladek
2021-01-26 21:15 ` [PATCH printk-rework 10/12] hv: " John Ogness
2021-01-27 21:32 ` Michael Kelley
2021-02-01 10:56 ` John Ogness
2021-01-26 21:15 ` [PATCH printk-rework 11/12] printk: remove logbuf_lock John Ogness
2021-02-02 9:15 ` Petr Mladek
2021-02-02 11:41 ` John Ogness
2021-02-02 16:11 ` Petr Mladek
2021-01-26 21:15 ` [PATCH printk-rework 12/12] printk: kmsg_dump: remove _nolock() variants John Ogness
2021-02-02 9:45 ` Petr Mladek
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=87r1m02o2d.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox