lkml.org 
[lkml]   [2020]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [GIT pull] locking/urgent for 5.10-rc3
    On Sun, Nov 8, 2020 at 7:24 AM Thomas Gleixner <tglx@linutronix.de> wrote:
    >
    > A single fix for the futex code where an intermediate state in the
    > underlying RT mutex was not handled correctly and triggering a BUG()
    > instead of treating it as another variant of retry condition.

    I'd just like to point out that the old code was *exactly* the kind of
    code that I've been ranting about forever.

    BUG_ON() is not a debug aid. If it's a "cannot happen" condition, you
    don't write any code for it at all. And if it's a "I'm not sure this
    cannot happen", you either handle it (like this patch does), or you do
    a "WARN_ON()" with proper cleanup.

    Using BUG_ON() is never the right thing to do, unless you can explain
    why the condition is some kind of fatal corruption thing where you
    cannot do cleanup, and cannot just ignore it.

    And so often - and this case doesn't look different - a BUG_ON() will
    cause serious kernel issues, including locks held that may well cause
    fundamental problems downstream for users even reporting the BUG to
    anybody else.

    This particular BUG_ON seems to be three years old, so clearly very
    hard to hit. Or possibly very hard to report? Regardless, please
    people, keep the whole "BUG_ON() is evil and wrong" in mind.

    Linus

    \
     
     \ /
      Last update: 2020-11-08 19:05    [W:3.751 / U:0.184 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site