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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7eac3a36-d2a2-400f-a4a2-7cec245a2709@linux.dev>
Date: Fri, 5 Dec 2025 09:44:05 +0800
From: ChenXiaoSong <chenxiaosong.chenxiaosong@...ux.dev>
To: Steve French <smfrench@...il.com>
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

Now, where should common/smb2maperror.c go? Should it be built into both 
cifs.ko and ksmbd.ko?

Thanks,
ChenXiaoSong.

On 12/5/25 09:36, Steve French wrote:
> 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>
>>
> 
>