linux-kernel - Re: [PATCH] mm/debug: Change BUG_ON() crashes to survivable WARN

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: <CA+55aFzSLPSURQJ8TixTb_=+Ot51otRTBY0d8Tqg0+_zJiChZw@mail.gmail.com>
Date:   Thu, 7 Sep 2017 13:50:40 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
        Borislav Petkov <bpetkov@...e.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH] mm/debug: Change BUG_ON() crashes to survivable WARN_ON() warnings

On Thu, Sep 7, 2017 at 12:01 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> On a related note, this bug could have been more debuggable I think.
> Could we _please_ change VM_BUG_ON() to WARN_ON() or such?

I think it should be WARN_ON_ONCE(), or at least rate-limited some way.

Because once you have one of the VM bugs, they tend to repeat.

(We had a discussion long ago about making the "ONCE" behavior
actually be "once in a blue moon", and just mean that you warn at most
once every five minutes or something like that. Because the "once"
behavior has also resulted in people missing bugs, because the machine
has been up a long time, and maybe you got a warning at boot time, but
then five days later something fails silently again).

Also, should you do a "dump_vma()" if you then don't give a call stack
because you already did it earlier? So the rate limiting would need to
cover that part too, methinks.

                  Linus