linux-kernel - Re: [PATCH 09/10] smb: create common/common.h and common/common.c

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: <CAH2r5mv74OszZ610pTn+vZq3ubRdx=+au=SHRNFpyt2rigKkYQ@mail.gmail.com>
Date: Thu, 4 Dec 2025 19:36:48 -0600
From: Steve French <smfrench@...il.com>
To: ChenXiaoSong <chenxiaosong.chenxiaosong@...ux.dev>
Cc: Namjae Jeon <linkinjeon@...nel.org>, sfrench@...ba.org, linkinjeon@...ba.org, 
	linux-cifs@...r.kernel.org, linux-kernel@...r.kernel.org, 
	chenxiaosong@...nxiaosong.com, ChenXiaoSong <chenxiaosong@...inos.cn>
Subject: Re: [PATCH 09/10] smb: create common/common.h and common/common.c

i lean against an 'smbcommon.ko'   - it can be helpful to move common
code (headers, #defines etc) into fs/smb/common but other than
smbdirect code (where smbdirect.ko makes sense for cifs.ko, ksmbd.ko,
Samba and user space AI apps e.g. to use), I lean against creating new
modules for the client and server.

ksmbd.ko for server code
cifs.ko (or maybe someday renamed to smb3.ko) for client code
smbdirect.ko for the RDMA/smbdirect code shared by ksmbd/cifs.ko/userspace tools

maybe (as they did for the md4 code creating an cifs_md4.ko so that
less secure code doesn't have to be linked in if unneeded) someday we
could split an "smb1.ko" out for the SMB1 related code (since we want
to discourage use of old insecure dialects, and could shrink cifs.ko,
and slightly simplify it)

Finding common code is good - but let's not complicate things by
creating lots of new modules - in the short term the focus is on
sanely splitting the common RDMA/smbdirect code out (because 1) it is
large enough 2) it will have use cases outside of cifs.ko and
ksmbd.ko).  But I lean against creating multiple new modules in the
short term.

On Thu, Dec 4, 2025 at 6:59 PM ChenXiaoSong
<chenxiaosong.chenxiaosong@...ux.dev> wrote:
>
> OK, I will create new smb2maperror.ko and will send v2 soon.
>
> Thanks for your review and suggestions.
>
> Thanks,
> ChenXiaoSong.
>
> On 12/5/25 08:35, Namjae Jeon wrote:
> > On Thu, Dec 4, 2025 at 2:00 PM <chenxiaosong.chenxiaosong@...ux.dev> wrote:
> >>
> >> From: ChenXiaoSong <chenxiaosong@...inos.cn>
> >>
> >> Preparation for moving client/smb2maperror.c to common/.
> >>
> >> We can put cifs_md4 and smb2maperror into a single smb_common.ko,
> >> instead of creating two separate .ko (cifs_md4.ko and smb2maperror.ko).
> > Sorry, I prefer not to create new *.ko for only smb2maperror.
> >>
> >>    - rename md4.h -> common.h, and update include guard
> >>    - create common.c, and move module info from cifs_md4.c into common.c
> > ksmbd does not use md4 in smb/common, I don't prefer this either.
> > I would appreciate it if you could send me the patch set again except these.
> >>
> >> Signed-off-by: ChenXiaoSong <chenxiaosong@...inos.cn>
>


-- 
Thanks,

Steve