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]

Message-ID: <CAH2r5muRG45L3bNsNV1LJ_komzbp-js11sn+EfQ6Ys6b=X683Q@mail.gmail.com>
Date:   Sun, 21 May 2023 23:38:23 -0500
From:   Steve French <smfrench@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
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>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [GIT PULL] ksmbd server fixes

On Sun, May 21, 2023 at 2:21 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> 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

Here are two patches:
1)  Move CIFS/SMB3 related client and server files (cifs.ko and ksmbd.ko
and helper modules) to new fs/smb subdirectory (fs/smbfs was not used
to avoid confusion with the directory of the same name removed in 2.6.27
release and we also avoid using CONFIG_SMB_FS for the same reason)

   fs/cifs --> fs/smb/client
   fs/ksmbd --> fs/smb/server
   fs/smbfs_common --> fs/smb/common

2) With the fs/cifs directory moved to fs/smb/client, correct mentions
of this in Documentation and comments.

Follow on patch can change Documentation/filesystems/cifs -->
Documentation/filesystems/smb (since it contains both server
and client documentation)


--
Thanks,

Steve

Download attachment "0001-smb-move-client-and-server-files-to-common-directory.patch" of type "application/x-patch" (43387 bytes)

Download attachment "0002-cifs-correct-references-in-Documentation-to-old-fs-c.patch" of type "application/x-patch" (5631 bytes)