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  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 Apr 2018 11:52:48 -0700
From:   Linus Torvalds <>
To:     Steven Rostedt <>
Cc:     Sasha Levin <>,
        Pavel Machek <>, Petr Mladek <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        Cong Wang <>,
        Dave Hansen <>,
        Johannes Weiner <>,
        Mel Gorman <>, Michal Hocko <>,
        Vlastimil Babka <>,
        Peter Zijlstra <>, Jan Kara <>,
        Mathieu Desnoyers <>,
        Tetsuo Handa <>,
        Byungchul Park <>,
        Tejun Heo <>, Greg KH <>
Subject: Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and
 waiter logic to load balance console writes

On Mon, Apr 16, 2018 at 11:41 AM, Steven Rostedt <> wrote:
>I never said the second
> bug fix should not have been backported. I even said that the first bug
> "didn't go far enough".

You're still not getting it.

The "didn't go far enough" means that the bug fix is *BUGGY*. It needs
to be reverted.

> I hope the answer was not to revert the bug and put back the possible
> bad memory access in to keep API.

But that very must *IS* the answer. If there isn't a fix for the ABI
breakage, then the first bugfix needs to be reverted.

Really. There is no such thing as "but the fix was more important than
the bug it introduced".

This is why we started with the whole "actively revert things that
introduce regressions". Because people always kept claiming that "but
but I fixed a worse bug, and it's better to fix the worse bug even if
it then introduces another problem, because the other problem is


We're better off making *no* progress, than making "unsteady progress".

Really. Seriously.

If you cannot fix a bug without introducing another one, don't do it.
Don't do kernel development.

The whole mentality you show is NOT ACCEPTABLE.

So the *only* answer is: "fix the bug _and_ keep the API".  There is
no other choice.

The whole "I fixed one problem but introduced another" is not how we
work. You should damn well know that. There are no excuses.

And yes, sometimes that means jumping through hoops. But that's what
it takes to keep users happy.


Powered by blists - more mailing lists