linux-kernel - Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads

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: <20170628134251.GQ1538@pathway.suse.cz>
Date:   Wed, 28 Jun 2017 15:42:51 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Jan Kara <jack@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Eric Biederman <ebiederm@...ssion.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>, Pavel Machek <pavel@....cz>,
        Andreas Mohr <andi@...as.de>,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads

On Thu 2017-06-08 17:18:29, Sergey Senozhatsky wrote:
> we still don't have guarantees that printk_kthread will be scheduled on
> a CPU that can run it immediately or anytime in the future, but not too
> late. printk_kthread can even be scheduled on the CPU that has requested
> offloading in the first place (am I wrong on this assumption?). which means
> that printk_kthread may not be able to take over (think of a printk() dump
> from IRQ context). that's the reason why I additionally want to
> console_trylock() for PRINTK_PENDING_PRINTK_OFFLOAD.
> 
> 
> but console_trylock() is not really reliable. not at all. it's a very fast
> one shot action that most likely will see console_sem still being locked
> but the CPU that has requested offloading. I want something to wait on
> console_sem, that's reliably. and we need woken up (running) printk_kthread
> for that.
> 
> 
> may be... we can set CPU affinity on printk_kthread before we wake it up?
> place into rq of the CPU that is processing PRINTK_PENDING_PRINTK_OFFLOAD?
> 
> or allow it on any CPU but the currently printing CPU.
> 
> or have per-CPU printk kthreads and wake_up processes that are already
> bound to specific rq-s. (I know it's ugly, to put it politely. I'm just
> trying different solutions/approaches).

My head is whirling when thinking about all the per-CPU stuff. It is
looking for escape. The way is to keep it as simple as possible.

After all, we should need all this only when there is a flood of
messages. Otherwise, the messages should be handled immediately
within atomic_print_limit.

If there is a flood of messages and we do not sleep inside
console_unlock(), there should always be a new volunteer that
would continue with console flushing.

It the flood stops and the system works, we should have enough
time to recover. If the system stops working during the flood
then I am afraid that even the per-CPU kthreads would not help
much.

Does this makes sense? Or did my head hide some important aspect
again?

Best Regards,
Petr