linux-kernel - Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test

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: <20170410150820.GB457@tigerII.localdomain>
Date:   Tue, 11 Apr 2017 00:08:20 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:     Petr Mladek <pmladek@...e.com>, Pavel Machek <pavel@....cz>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Jan Kara <jack@...e.cz>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Ye Xiaolong <xiaolong.ye@...el.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>, Len Brown <len.brown@...el.com>,
        linux-kernel@...r.kernel.org, lkp@...org
Subject: Re: [printk]  fbc14616f4:
 BUG:kernel_reboot-without-warning_in_test_stage

On (04/10/17 13:54), Petr Mladek wrote:
[..]
> > > that works with my proposal, but not with yours. Seen it happen many
> > > times before.
> > 
> > I see your point, sure.
> > I can't completely agree on "that works with my proposal, but not with yours."
> > 
> > on SMP system this would be true only if no other CPU holds the console_sem
> > at the time we call printk(). (skipping irrelevant cases when we have suspended
> > console or !online CPU and !CON_ANYTIME console). and there is nothing that
> > makes "no other CPU holds the console_sem" always true on SMP system at any
> > given point in time. so no, "A always works, B never works" is not accurate.
> > 
> > but, once again, I see your point.
> 
> A compromise might be to move the offloading from vprintk_emit() to
> console_unlock(). By other words, the printk could always try to
> flush some messages to the console. The console might trigger
> the offload (wakeup kthread) after few lines

yep, that's the proposal.

hm, this also should align with one more thing.

we briefly discussed it before, and it was on my list, that
wake_up(printk_kthread) _eventually_ better be moved to console_unlock()
[1] (I also had it in the slides at KS, but I believe we didn't have much
time back then).

vprintk_emit() is not the only console_lock() caller. user space does
console_lock() and console_unlock() calls, and in some cases a user
space process can stuck in system call printing kernel messages to a
potentially slow console [2]. it can be unpleasant, but far less dramatic
than doing console_unlock() from IRQ, or under spin_lock. so it was
moved down the list. seems we have one more reason to reshuffle the
list and do offloading from console_unlock() from the beginning.

will take a look.

/* in our "in-house" kernels we do 'async' console_unlock(). not
exactly the way it's shown in [1], but quite similar. */

[1] https://marc.info/?l=linux-kernel&m=145750373530161
[2] https://marc.info/?l=linux-kernel&m=145762735308470

	-ss