Re: [RFC PATCH] cmdline: Hide "debug" from /proc/cmdline

["Theodore Ts'o" <tytso@mit.edu>]

On Thu, Apr 03, 2014 at 12:43:08PM +0200, Joerg Roedel wrote:
> 
> How about just ignoring writes to /dev/kmsg altogether by default
> (unless explicitly enabled in Kconfig or on the kernel cmdline)? Maybe I
> am missing something but what are the legitimate use-cases for generally
> allowing user-space to write into the kernel-log?

I'll give you one example which where /dev/kmesg is useful --- if you
are running automated kernel tests, echoing "running test shared/127"
.... several minutes later .... "running test shared/128", is very
useful since if the kernel starts spewing warnings, or even
oops/panics/livelocks, you know what test was running at the time of
the failure.

So in general, most of the valid use cases I can see for /dev/kmesg
are small amounts of information where understanding the relationship
between what is going in userspace can help understand the kernel
warnings, errors, or other printk messages.  Which is why I think rate
limiting, even with a very low threshold, is a perfectly good alternative.

If you need to do bulk logging, and the problem is you want to make
sure the information doesn't get lost because syslogd/journald hasn't
started up yet, or the file system hasn't been remounted read/write
yet, there is a simple answer to this, and it doesn't involve spamming
the kernel ring buffer (because kernel memory is non-swappable).

The answer is logsave(8), which I developed to solve this specific
problem.  I wanted to make sure distributions could capture the output
of fsck, even when checking the read-only root file system.  Note that
I did not even *consider* spamming the dmesg log with e2fsck output.
Instead, I created a userspace logsave process which could buffer the
output (which of course was still displayed on the console) until the
root file system was writeable (and/or /var was mounted), at which
point the contents could be saved to a file in /var/log.

So there are so many other ways of solving this problem without trying
to abuse the kernel logging facilities (which were never intended to
be a general-purpose syslog replacement).  I suspect some systemd
developer was being lazy....

					- Ted