linux-kernel - Re: [RFC] printk/sysrq: Don't play with console

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: <20190611151018.gvjazu4vedw2h2qh@pathway.suse.cz>
Date:   Tue, 11 Jun 2019 17:10:18 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Pavel Machek <pavel@....cz>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Dmitry Safonov <dima@...sta.com>, linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC] printk/sysrq: Don't play with console_loglevel

On Sat 2019-06-08 11:45:45, Tetsuo Handa wrote:
> On 2019/06/08 2:09, Pavel Machek wrote:
> > On Tue 2019-05-28 19:15:43, Tetsuo Handa wrote:
> >> On 2019/05/28 17:51, Sergey Senozhatsky wrote:
> >>>> You are trying to omit passing KERN_UNSUPPRESSED by utilizing implicit printk
> >>>> context information. But doesn't such attempt resemble find_printk_buffer() ?
> >>>
> >>> Adding KERN_UNSUPPRESSED to all printks down the op_p->handler()
> >>> line is hardly possible. At the same time I'd really prefer not
> >>> to have buffering for sysrq.
> >>
> >> I don't think it is hardly possible. And I really prefer having
> >> deferred printing for SysRq.

> > 
> > Well, magic SysRq was meant for situation where system is in weird/broken state.
> > "Give me backtrace where it is hung", etc. Direct printing is more likely to work
> > in that cases.
> 
> Magic SysRq from keyboard is for situation where system is in weird/broken state.
> 
> But I want to use Magic SysRq from /proc for situation where system is not fatally
> weird/broken state. I have trouble getting SysRq-t from /proc when something bad
> happened (e.g. some health check process did not return for 60 seconds). Since
> /proc/pid/wchan shows only 1 line, it is useless for understanding why that process
> got stuck. If direct printing is enforced, "echo t > /proc/sysrq-trigger" might take
> many minutes. If direct printing is not enforced, "echo t > /proc/sysrq-trigger"
> should complete within less than one second. If syslog is working (which is almost
> equivalent to being able to write to /proc/sysrq-trigger), the latter is more helpful
> for taking snapshots for multiple times (e.g. 5 times with 10 seconds interval) in
> order to understand why that process got stuck. That's why I added

This looks like a very specific use case. But the proposal changes
the behavior for anyone. I am not persuaded that everyone would
appreciate the change.

OK, it takes 60 seconds when the messages appear on the console and
1 second when they are just stored to the syslog.

Why the system is configured to show all messages on the console
when syslog is enough?

If sysrq is the preferred interface, it might be used also the other
way. I mean to increase console_loglevel to hide all messages on
the console, trigger output of the system state and eventually
decrease the loglevel again.

> Also, regarding Magic SysRq from keyboard case, my intent is to allow SysRq
> to just store the messages to printk() buffer, in order to avoid stalls and
> take better snapshots for multiple times. And my intent of
> 
>   And I really prefer having deferred printing for SysRq.

Always deferring printk() for everyone is not acceptable. It is one
extreme between printk() reliability and speed in favor of the speed.
But many people prefer reliability (high chance to see messages
when the system goes down.

IMHO, the only acceptable solution need to be configurable:

   + never deffer (debugging corner cases?)
   + avoid softlockup (default on normal systems?)
   + guarantee max time (throughput oriented systems)
   + always deffer (real time, special usecases)

It might be based on Sergey's patchsets adding the offload logic
into console_unlock().

IMHO, the most problematic thing is how to define the limit
(lines?, characters?, time?). A limit bases on the data amount
would also depend on console speed. Time based limit would be
better but measuring time in console_unlock() is problematic
(atomic context, possible deadlocks).

Best Regards,
Petr