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: <CAHk-=wiOm8x5KnBQH+FYN76sSjCeP2_9cxgzu4WArR3jP0MD8g@mail.gmail.com>
Date:   Thu, 1 Nov 2018 15:00:34 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:     rostedt@...dmis.org, tglx@...utronix.de,
        Peter Zijlstra <peterz@...radead.org>,
        Paul McKenney <paulmck@...ux.vnet.ibm.com>,
        boqun.feng@...il.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-api@...r.kernel.org, luto@...capital.net, davejwatson@...com,
        Paul Turner <pjt@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux@....linux.org.uk, Ingo Molnar <mingo@...hat.com>,
        Peter Anvin <hpa@...or.com>, andi@...stfloor.org,
        Christoph Lameter <cl@...ux.com>, bmaurer@...com,
        josh@...htriplett.org, Catalin Marinas <catalin.marinas@....com>,
        will.deacon@....com,
        Michael Kerrisk-manpages <mtk.manpages@...il.com>,
        Joel Fernandes <joelaf@...gle.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        mawilcox@...rosoft.com
Subject: Re: [RFC PATCH for 4.21 03/16] mm: Replace BUG_ON() by WARN_ON() in vm_unmap_ram()

On Thu, Nov 1, 2018 at 12:57 PM Mathieu Desnoyers
<mathieu.desnoyers@...icios.com> wrote:
>
> > I think the graceful recovery is to simply return:
> >
> >       if (WARN_ON(cond))
> >               return;
> >
> > is better than just
> >
> >       BUG_ON(cond);
> >
> > As that's what Linus made pretty clear at the Maintainer's Summit.
>
> That's it. For an unmap function, this basically boils down to
> print a warning and leak the memory on internal unmap error.
>
> I will update the commit message describing this behavior.

It might be even better to use WARN_ON_ONCE().

If it's a "this shouldn't happen" situation, the advantage of
WARN_ON_ONCE() is that it will still show the backtrace of the "how
the heck did it happen after all" situation, but if it turns ouit to
be user-triggerable (or simply triggerable by some odd hw situation),
it won't spam your logs forever.

Obviously, things like rate limiting etc can also be good ideas, but
that's just overkill for "this really should never happen" cases.

(Side note: WARN_ON_ONCE() will _warn_ just once, but will always
return the condition that it warns for, so the return value is _not_
"I have warned", but "I have seen the condition that I should warn
about". Just in case people are worried about it).

                  Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ