linux-kernel - Re: [GIT PULL] CIFS/SMB3 fixes

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]

Date:   Wed, 8 May 2019 13:46:44 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Steve French <smfrench@...il.com>
Cc:     CIFS <linux-cifs@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] CIFS/SMB3 fixes

On Wed, May 8, 2019 at 1:37 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> So don't do the whole "rebase the day before" in the first place, but
> *DEFINITELY* don't do it when you then pick a random and bad point to
> rebase things on top of!

I've pulled, but I really hope this never happens again.

You could have rebased your work on top of 5.1 if you needed to.

Or you could have just tried to avoid rebasing in the first place.

But picking a random commit that was the top-of-the-tree on the second
day of the merge window (pretty much when things are at their most
chaotic) is just about the worst thing you can do.

I'm considering adding some automation to my pull requests to warn
about craziness like this. Because maybe you've consistently done
something like this in the past, and I've just not noticed how crazy
the pull request was.

               Linus