lkml.org 
[lkml]   [2016]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -v4 2/2] printk: Add kernel parameter to control writes to /dev/kmsg
On 07/18/16 at 11:06am, Borislav Petkov wrote:
> On Mon, Jul 18, 2016 at 04:17:12PM +0800, Dave Young wrote:
> > Because IMHO it is wrong, they can not be ratelimited because the writing could
> > be from different userspace programs.
>
> It is ratelimited by interface openers.

You are thinking from kernel point of view, but it will be different from
a user point of view.

>
> > Simply ratelimiting different sources of writing is pointless to me.
>
> So what are you arguing for? What is the *actual* *real-life* *use* case
> you think will be handicapped?
>
> > One can only see messages they would like to see by luck, it is worse
> > than off.
>
> THAT'S WHY YOU BOOT WITH "printk.devkmsg=on" TO SEE THEM ALL!
>
> The /dev/kmsg thing was added for the more or less, wrong, historic
> reasons and userspace started abusing it and interfering with kernel
> operation. That's why we're adding this tristate option.
>
> In the default case we're ratelimiting writes to it because they should
> not interfere with kernel operation.
>
> [ Frankly, those writes are pretty much useless to the normal user so
> we can just as well ignore them but WTH. ]
>
> So give me a concrete problem you see with the ralimiting and not some
> notion of a feeling you might have of it being pointless, ok?

Ok, for example below (A and B can be any program, systemd or other logging
utility, dracut scripts...)

Program A:
for (i = 0; i < 100; i++)
write an error message A1

for (i =0; i < 100; i++)
write an error message A2

Program B:
for (i = 0; i < 100; i++)
write an error message B1

for (i =0; i < 100; i++)
write an error message B2

In above case, ratelimit specific message like A1 is reasonable, but simply
ratelimit the writing to /dev/kmsg will cause the final messages appear are
uncertain. This is not ratelimit should do.

We provide a default printk.devkmsg, it should either works or not, the
middle point is just wrong because it helps nothing, so what is the benefit
of the ratelimit compares with "off"? If there's no benefits why we will
make the code complicate?

Thanks
Dave

\
 
 \ /
  Last update: 2016-07-19 03:01    [W:0.090 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site