linux-kernel - Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

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: <20171218141037.m6o6bicx5xhpjbl6@pathway.suse.cz>
Date:   Mon, 18 Dec 2017 15:10:37 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>, Tejun Heo <tj@...nel.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Jan Kara <jack@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Rafael Wysocki <rjw@...ysocki.net>,
        Pavel Machek <pavel@....cz>,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

On Mon 2017-12-18 14:31:01, Petr Mladek wrote:
> On Mon 2017-12-18 18:36:15, Sergey Senozhatsky wrote:
> > -  it has a significantly worse behaviour compared to old async printk.
> > -  it keeps sleeping on console_sem tasks in TASK_UNINTERRUPTIBLE
> >       for a long time.
> > -  it timeouts user space apps.
> > -  it re-introduces the lockup vector, by passing console_sem ownership
> >       to atomic tasks.
> 
> All this is in the current upstream code as well. Steven's patch
> should make it better in compare with the current upstream code.
> 
> Sure, the printk offload approach does all these things better.
> But there is still the fear that the offload is not reliable
> in all situations. The lazy offload should handle this well from
> my POV but I am not 100% sure.

BTW: There is one interesting thing. If we rely on the kthread
to handle flood of messages. It might be too slow because it
reschedules. It might cause loosing messages. Note that
the kthread should have rather normal priority to avoid
blocking other processes.

>From this point of view. We get the messages out much faster
in an atomic context. The question is if we want to sacrifice
the atomic context of a random process for this.

Just an idea. The handshake + throttling big sinners might
help to balance the load over the biggest sinners (printk
users).

The nice think about the hand-shake + throttling  based approach
is that it might be built step by step. Each step would just
make things better. While the offloading is rather a big
revolution. We already have many extra patches to avoid
regressions in the reliability.

One thing is that we play with offloading for years. The handshake
might have problems that we just do not know about at the moment.
But it definitely has some interesting aspects.

Best Regards,
Petr