linux-kernel - Re: [RFC PATCH v1 00/25] printk: new implementation

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20190314092727.m37frq3jszz6mh4g@pathway.suse.cz>
Date:   Thu, 14 Mar 2019 10:27:27 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     Sebastian Siewior <bigeasy@...utronix.de>,
        John Ogness <john.ogness@...utronix.de>,
        linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Daniel Wang <wonderfly@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Jiri Slaby <jslaby@...e.com>,
        Peter Feiner <pfeiner@...gle.com>,
        linux-serial@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [RFC PATCH v1 00/25] printk: new implementation

On Wed 2019-03-13 18:27:59, Sergey Senozhatsky wrote:
> On (03/13/19 09:40), Sebastian Siewior wrote:
> > On 2019-03-13 09:19:32 [+0100], John Ogness wrote:
> > > recursive situation. As you are pointing out, the notification/wake
> > > component of printk_safe will still be needed. I will leave that (small)
> > > part in printk_safe.c.
> > 
> > Does this mean we keep irq_work part or we bury it and solve it by other
> > means?
>
> *May be* we can take a closer look and find cases when ->atomic
> consoles don't really depend on console_sem. And *may be* we can
> split the console drivers list and somehow forbid removal and
> modification (ioctl) of ->atomic consoles under us. Assuming that
> this is doable we then can start iterating ->atomic consoles list
> with unlocked console_sem.

I believe that this is actually the plan. Atomic consoles depending
on console_sem would not be a real step forward.


> Non->atomic consoles or consoles which depend on console_sem (VT,
> fbcon and so on) will stay in another list, and we will take
> console_sem before we iterate that list and invoke those drivers.

This might be also needed for "less" important messages
that people would not want to get to the console atomically
because it would serialize CPUs and slow down the entire
system.

I think that we would still need irq_work for this mode.
But it should be necessary only for messages from NMI context
and printk() recursion. It means that it should be a rare
situation and the amount of messages should get limited.
It should not be much worse than handling few printk()
calls from any irq handler.

Best Regards,
Petr