linux-kernel - Re: [GIT PULL] ksmbd server 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:   Sun, 21 May 2023 12:21:20 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Steve French <smfrench@...il.com>
Cc:     Namjae Jeon <linkinjeon@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        CIFS <linux-cifs@...r.kernel.org>,
        samba-technical <samba-technical@...ts.samba.org>
Subject: Re: [GIT PULL] ksmbd server fixes

On Sun, May 21, 2023 at 12:03 PM Steve French <smfrench@...il.com> wrote:
>
> I would be happy to do the move (to fs/smb) of the directories and
> update the config soon (seems reasonably low risk) - let me know if you
> want me to send it this week or wait till 6.5-rc

So I think the "do it now or wait until the 6.5 merge window" is
entirely up to you.

We've often intentionally done big renames during the "quiet time"
after the merge window is oven, just because doing them during the
merge window can be somewhat painful with unnecessary conflicts.

I would *not* want to do it during the last week of the release, just
in case there are small details that need to be fixed up, but doing it
now during the rc3/rc4 kind of timeframe is not only fairly quiet, but
also gives us time to find any surprises.

So in that sense, doing it now is likely one of the better times, and
a pure rename should not be risky from a code standpoint.

At the same time, doing it during the merge window isn't *wrong*
either.  Despite the somewhat painful merge with folio changes, I
don't think fs/cifs/ or fs/ksmbd/ normally have a lot of conflicts,
and git does handle rename conflicts fairly well unless there's just
lots of complexity.

So it's really fine either way. The normal kind of "big changes"
should obviously always be merge window things, but pure renames
really are different and are often done outside of the merge window
(the same way I intentionally did the MAINTAINERS re-ordering just
*after* the merge window)

But we don't do renames often enough to have any kind of strict rules
about things like this.

So I think "whenever is most convenient for you" is the thing to aim
for here. This is *not* a "only during merge window" kind of thing.

                 Linus