Re: [PATCH printk v3 6/6] printk: introduce console_prepend_dropped() for dropped messages

[John Ogness <john.ogness@linutronix.de>]

On 2023-01-03, Petr Mladek <pmladek@suse.com> wrote:
>> Unless you think it is OK to kmalloc 8KB instead of 1KB for the
>> syslog calls. Then yes, we do not need SYSLOG_MESSAGE_MAX.
>
> IMHO, it is acceptable and even correct. syslog uses the same
> prefixes as console. It would make sense to use the same
> buffers for formatting.
>
> That said, 8kB looks non-necessary big to me.
>
> It seems that it comes from devkmsg interface, see the commit
> d43ff430f434d862db59582 ("printk: guard the amount written
> per line by devkmsg_read()"). It was supposed to include
> the message, the extended prefix and dictionary, where
>
>    + message is limited by LOG_LINE_MAX
>    + prefix includes few well defined fields (should be < 128B)
>    + dictionary comes from dev_printk() => ( < 128B as well)
>
> I believe that 2kB or 4kB would be perfectly fine.

The main issue is multi-line records. Normal messages become _much_
larger than extended messages in this case because they add a prefix per
'\n', whereas extended messages just use "\x0a". Extended messages
really could only end up being significantly longer than normal messages
if there are many non-printable characters in the message. But AFAIK
non-printables are not really used in printk messages.

So IMHO it does not make sense that normal messages are limited to 1KB
but extended messages can use 8KB. I agree that a universal limit of 2KB
for normal/extended/syslog would be a nice compromise. Normal messages
will have more space available and it will reduce the overall static
buffer usage. It would mean that syslog calls will kmalloc 2KB instead
of 1KB, but I expect that should be acceptable since, generally
speaking, overall we are reducing memory usage.

John