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]
Date:   Mon, 16 Oct 2017 13:12:39 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>
Subject: Re: NMI watchdog dump does not print on hard lockup

On Fri 2017-10-13 12:12:29, Linus Torvalds wrote:
> On Fri, Oct 13, 2017 at 6:18 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > Or add the following case: The watchdog triggers, does the print, then
> > if it triggers again in a certain amount of time, and the print still
> > hasn't been flushed, the flush happens then.

Sounds good to me.

> By the time 40 sec has passed, I suspect most people have just
> rebooted the machine.

This might be the case for a desktop. But people might be more
conservative in case of big servers or when debugging. These might
be desperate to keep going or see something.

> I think an NMI watchdog should just force the flush - the same way an
> oops should. Deadlocks aren't really relevant if something doesn't get
> printed out anyway.

We expicititely flush the NMI buffers in panic() when there is
not other way to see them. But it is questional in other situations.
Sometimes the flush might be the only way to see the messages
and sometimes printk() might unnecessarily cause a deadlock.
IMHO, the only solution is to make it optional.

Best Regards,
Petr

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ