linux-kernel - Re: [PATCH 2/2] printk: wake up klogd in vprintk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180419095405.juihlwjqvd3ntmvi@pathway.suse.cz>
Date:   Thu, 19 Apr 2018 11:54:05 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] printk: wake up klogd in vprintk_emit

On Thu 2018-04-19 10:23:11, Sergey Senozhatsky wrote:
> On (04/18/18 16:04), Petr Mladek wrote:
> [..]
> > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > index 2f4af216bd6e..86f0b337cbf6 100644
> > > --- a/kernel/printk/printk.c
> > > +++ b/kernel/printk/printk.c
> > > @@ -1888,6 +1888,7 @@ asmlinkage int vprintk_emit(int facility, int level,
> > >  
> > >  	printed_len = log_output(facility, level, lflags, dict, dictlen, text, text_len);
> > >  
> > > +	wake_up_klogd();
> > >  	logbuf_unlock_irqrestore(flags);
> > 
> > In fact, I would feel more comfortable if we move this to the end
> > of vprintk_emit() right before return printk_len. This will be
> > more close to the current behavior (console first). But it will
> > still wakeup klogd much earlier and regularly if there is
> > a flood of messages.
> 
> Hm, the idea of the patch is that the existing "push everything to slow
> consoles first, then wakeup syslog" is not very robust.

I guess that you know why I suggested what I suggested ;-)
Just for record, I thought the following way:

The obsession about getting messages on consoles ASAP blocked
any softlockup prevention for years. There are surely situations
where this matter and we need to keep this in mind.

Loggers might preempt the current task because of priority
inversion. It is rather a corner case. The priority inversion is
problem on its own that probably do not have a good solution.

Our main target is to increase the chance to see the messages.
In theory userspace loggers might be faster than a slow console.
But they are not much reliable by definition. They need to get
scheduled, copy the message, store it into a file, the file need
to get synced to the disk. There are many things that might get
wrong there.

All in all, neither solution would work better in all situations.
I would just feel more comfortable if we do not go to the other
extreme, ...

> But probably we can do what you suggested, yes.

Thanks a lot for using this in v2.

Best Regards,
Petr