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: <CAHk-=wgA9JTgJRmRZeGESOgVfsS7g=G0BiVH+7pJ49iuo-G=Jg@mail.gmail.com>
Date:   Sun, 21 May 2023 11:32:59 -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>
Subject: Re: [GIT PULL] ksmbd server fixes

On Sun, May 21, 2023 at 11:06 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Would you mind horribly to just bite the bullet, and rename things,
> and put it all under "smbfs". Something like
>
>     mkdir fs/smbfs
>     git mv fs/cifs fs/smbfs/client
>     git mv fs/ksmbd fs/smbfs/server
>     git mv fs/smbfs_common fs/smbfs/common
>
> plus the required Makefile editing to just make it all build right?

Just because I wanted to test it, here's a patch that is based on the
above directory moves, with the (tiny) extra work to set up the
Kconfig and Makefile changes, and some trivial "fix up include file
paths".

It's "tested" in the sense that it passes an "allmodconfig" build for
me, but that's literally all I checked.

I *did* end up changing the Kconfig variable name for SMBFS_COMMON to
be just SMBFS. It made more sense that way with the re-org. And I
think the patch looks pretty good, with things like

  -#include "../smbfs_common/arc4.h"
  +#include "../common/arc4.h"

just looking better as a result of this all. No?

But what I did *not* do was to fix up things like paths in the
documentation build etc. The location of the resulting module.ko files
obviously change, for example, and I find a reference to
fs/cifs/ioctl.c in the ioctl list etc.

Again - I'm not at all saying that you *have* to do this. And I am
*not* going to commit this diff to my own tree, for example.

I'm just sending the diff out to make it really easy for you to try it
out if you happen to agree with what I'm suggesting.

What do you think?

                  Linus

View attachment "patch.diff" of type "text/x-patch" (36565 bytes)