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]
Date:   Wed, 20 Dec 2017 16:46:54 +0900
From:   Sergey Senozhatsky <>
To:     Steven Rostedt <>
Cc:     Sergey Senozhatsky <>,
        Petr Mladek <>, Tejun Heo <>,
        Sergey Senozhatsky <>,
        Jan Kara <>,
        Andrew Morton <>,
        Peter Zijlstra <>,
        Rafael Wysocki <>,
        Pavel Machek <>,
        Tetsuo Handa <>,
Subject: Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

On (12/19/17 09:40), Steven Rostedt wrote:
> On Tue, 19 Dec 2017 13:58:46 +0900
> Sergey Senozhatsky <> wrote:
> > so you are not convinced that my scenarios real/matter; I'm not
> Well, not with the test module. I'm looking for actual code in the
> upstream kernel.
> > convinced that I have stable and functional boards with this patch ;)
> > seems that we are coming to a dead end.
> Can I ask, is it any worse than what we have today?

that's a really hard question. both the existing printk() and the
tweaked printk() have the same thing in common - a) preemption from
console_unlock() and b) printk() being way to fast compared to anything
else (call_console_drivers() and to preemption latency of console_sem
owner). your patch puts some requirements that my workload simply cannot
fulfill. so may be if I'll start pushing it towards OOM and so on, then
I'll see some difference (but both (a) and (b) still gonna stay true).

the thing that really changes everything is offloading to printk_kthread.
given that I can't have a tiny logbuf, and that I can't have fast console,
and that I can't have tons of printks to chose from and to get advantage
of hand off algorithm in any reliable way; I need something more to
guarantee that the current console_sem will not be forced to evict all
logbuf messages.

> > for the record,
> > I'm not going to block the patch if you want it to be merged.
> Thanks,

I mean it :)


Powered by blists - more mailing lists