Re: [RFC][PATCH] printk: increase devkmsg write() ratelimit

[Sergey Senozhatsky]

On (12/20/18 08:58), Steven Rostedt wrote:
> > > Userspace processes should never be able to overwrite messages
> > > from the kernel.
> > 
> > I would agree.
> > 
> > It's a bit funny that kernel people first take the patch in and then,
> > when user-space begins to use the feature, start to object and ratelimit.
> 
> Please note the "kernel people" to first take it in, were also systemd
> developers.

Good point.

> Honestly, it should have been a separate buffer to begin with, and I
> wish I pushed for that when it was first added. It's not too late. We
> can still make it a separate buffer.

Ideally, yes, separating them will make sense.

[..]
> When the system is up and running, it works. But I believe systemd can
> still only use ksmsg for initial boot up messages before it does the
> chroot.
[..]
> Do you get systemd messages before chroot with this patch compared to
> what you get without it?

You are right.

systemd cannot log anything really early - there should be /dev/kmsg char
device so they can open() it and write() to it. IOW only after chr_dev_init()
they can append messages to devkmsg. Which is still early enough, perhaps
earlier than UART init. systemd can log to tty, but unlike logbuf messages,
messages written to tty cannot be re-played:

+->  chr_dev_init() create /dev/kmsg
|      persistent storage is not mounted yet
|      writes to /dev/kmsg work
|      ...
|    chroot
|    mount /dev/sdX
+->  journald starts
     pulls logbuf (devkmsg)
     syslog now works
     "systemd[1]: Starting Flush Journal to Persistent Storage..."

So without devkmsg some early systemd messages can be lost (between
chr_dev_init() and exec(journald)), just like you said; or (best case)
will go to serial log. Messages before chr_dev_init() will be lost
because there is no /dev/kmsg; messages after exec(journald) do not
necessarily depend on /dev/kmsg and can be logged via syslog/journal
interface.

	-ss