linux-kernel - Re: Linux 5.3-rc7

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: <20190908110253.GC2012@sasha-vm>
Date:   Sun, 8 Sep 2019 07:02:53 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Chris Wilson <chris@...is-wilson.co.uk>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Bandan Das <bsd@...hat.com>
Subject: Re: Linux 5.3-rc7

On Sat, Sep 07, 2019 at 02:13:22PM -0700, Linus Torvalds wrote:
>On Sat, Sep 7, 2019 at 1:44 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>>
>> That's what I just replied to Chris. Can you do it right away or should I queue it up?
>
>Done.

I'd like to bring back a discussion we had last year on ksummit-discuss:
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2018-May/005122.html
. I've pointed out that some of the commits that go in the -rc cycles
are of low quality and are untested, you seemed to agree but said that
it's "by-design" because late -rc cycle commits are more complex.

Is this commit and it's fallout really how our development process
should be working?

This commit was rushed through the process: it was authored and merged
into -tip of the same day, and pulled in by you just a few days later.
There was no meaningful time for review, testing, or really any sort of
QA.

We really do have a better story now for catching the sort of issues
introduced by these patch: multiple CI systems tripped on this, but
people still need the time to look into it, make sure that the failure
is real and bisect it.

What was the rush in making it skip all of our safeguards? The "bug" has
been there forever, the fix isn't urgent, and no one seemed to care for
quite a while.

Even if this patch was fixing a bug introduced in this merge window, is
the tradeoff around rushing an untested fix worth it vs giving it more
time and shipping it as part of our stable tree?

I'm not trying to pick on this patch in particular - I feel that this is
a systematic issue and should be addressed as part of our process.

--
Thanks,
Sasha