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] [day] [month] [year] [list]

Message-ID: <CAH2r5mu2tsupGjLQPK0z7va-FPdWb_WT0DKTYjZw-SW4=DCaRQ@mail.gmail.com>
Date:   Wed, 8 May 2019 16:47:43 -0500
From:   Steve French <smfrench@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
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 3:37 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Wed, May 8, 2019 at 11:32 AM Steve French <smfrench@...il.com> wrote:
> >
> >    [..] Our
> > build verification tests passed (and continue to be extended to
> > include more tests).  See e.g. our 'buildbot' results at:
> > http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/2/builds/199
>
> Still, is there any reason for that very late rebase?
>
> Why are all the commits so recent?

Most of the commits were from April, three from March, only a few more
recent. I rebased
yesterday (bad idea it seems based on your note) simply to avoid any potential
merge conflict with the two broad VFS changes (unrelated to my PR)
that hit cifs code yesterday (albeit they turned out to be very small).

> And perhaps even more importantly, why is the base for that rebase is
> some completely random and inappropriate commit in the middle of the
> merge window?

Understood. I had originally based it on v5.1 tag, but changed that
for testing after
I saw two other PR's hit I wanted to run the regression tests on
'current' mainline
with the changes in for-next code just in case (very unlikely) the other two
changes that I hadn't seen that hit cifs since 5.1 broke anything or
caused conflicts.

> 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!

Understood - will do the rebase for our verification testing only
(e.g. to spot any
regressions in recent global or VFS changes) but not for
sending to you.   So for future, will try to send with base as that of
mainline kernel
as of he last cifs PR  merge or new kernel version or rc (e.g.
v5.2-rc1 or v5.1 etc)
whichever is more recent.  Is that ok?

-- 
Thanks,

Steve