From: ChenXiaoSong <chenxiaosong@kylinos.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).
- rename md4.h -> common.h, and update include guard
- create common.c, and move module info from cifs_md4.c into common.c
Signed-off-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
---
fs/smb/client/smbencrypt.c | 2 +-
fs/smb/common/Makefile | 3 ++-
fs/smb/common/cifs_md4.c | 5 +----
fs/smb/common/common.c | 28 ++++++++++++++++++++++++++++
fs/smb/common/{md4.h => common.h} | 14 +++++++-------
5 files changed, 39 insertions(+), 13 deletions(-)
create mode 100644 fs/smb/common/common.c
rename fs/smb/common/{md4.h => common.h} (86%)
diff --git a/fs/smb/client/smbencrypt.c b/fs/smb/client/smbencrypt.c
index 1d1ee9f18f37..abbedcdf7613 100644
--- a/fs/smb/client/smbencrypt.c
+++ b/fs/smb/client/smbencrypt.c
@@ -24,7 +24,7 @@
#include "cifsglob.h"
#include "cifs_debug.h"
#include "cifsproto.h"
-#include "../common/md4.h"
+#include "../common/common.h"
/* following came from the other byteorder.h to avoid include conflicts */
#define CVAL(buf,pos) (((unsigned char *)(buf))[pos])
diff --git a/fs/smb/common/Makefile b/fs/smb/common/Makefile
index 9e0730a385fb..4f1dc5123e99 100644
--- a/fs/smb/common/Makefile
+++ b/fs/smb/common/Makefile
@@ -3,4 +3,5 @@
# Makefile for Linux filesystem routines that are shared by client and server.
#
-obj-$(CONFIG_SMBFS) += cifs_md4.o
+obj-$(CONFIG_SMBFS) += smb_common.o
+smb_common-objs := common.o cifs_md4.o
diff --git a/fs/smb/common/cifs_md4.c b/fs/smb/common/cifs_md4.c
index 7ee7f4dad90c..c619c0daf217 100644
--- a/fs/smb/common/cifs_md4.c
+++ b/fs/smb/common/cifs_md4.c
@@ -22,10 +22,7 @@
#include <linux/string.h>
#include <linux/types.h>
#include <asm/byteorder.h>
-#include "md4.h"
-
-MODULE_DESCRIPTION("MD4 Message Digest Algorithm (RFC1320)");
-MODULE_LICENSE("GPL");
+#include "common.h"
static inline u32 lshift(u32 x, unsigned int s)
{
diff --git a/fs/smb/common/common.c b/fs/smb/common/common.c
new file mode 100644
index 000000000000..4142e05039c0
--- /dev/null
+++ b/fs/smb/common/common.c
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) International Business Machines Corp., 2009
+ * 2018 Samsung Electronics Co., Ltd.
+ * Author(s): Steve French <sfrench@us.ibm.com>
+ * Namjae Jeon <linkinjeon@kernel.org>
+ */
+
+#include <linux/module.h>
+#include "common.h"
+
+static int __init smb_common_init(void)
+{
+ int rc = 0;
+
+ return rc;
+}
+
+static void __exit smb_common_exit(void)
+{
+}
+
+MODULE_AUTHOR("Steve French <stfrench@microsoft.com>");
+MODULE_AUTHOR("Namjae Jeon <linkinjeon@kernel.org>");
+MODULE_DESCRIPTION("Linux kernel SMB common");
+MODULE_LICENSE("GPL");
+module_init(smb_common_init)
+module_exit(smb_common_exit)
diff --git a/fs/smb/common/md4.h b/fs/smb/common/common.h
similarity index 86%
rename from fs/smb/common/md4.h
rename to fs/smb/common/common.h
index 5337becc699a..07ee24ecccb8 100644
--- a/fs/smb/common/md4.h
+++ b/fs/smb/common/common.h
@@ -1,13 +1,14 @@
/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Common values for ARC4 Cipher Algorithm
- */
-#ifndef _CIFS_MD4_H
-#define _CIFS_MD4_H
+#ifndef __SMB_COMMON_H__
+#define __SMB_COMMON_H__
#include <linux/types.h>
+/*
+ * Common values for ARC4 Cipher Algorithm
+ */
+
#define MD4_DIGEST_SIZE 16
#define MD4_HMAC_BLOCK_SIZE 64
#define MD4_BLOCK_WORDS 16
@@ -19,9 +20,8 @@ struct md4_ctx {
u64 byte_count;
};
-
int cifs_md4_init(struct md4_ctx *mctx);
int cifs_md4_update(struct md4_ctx *mctx, const u8 *data, unsigned int len);
int cifs_md4_final(struct md4_ctx *mctx, u8 *out);
-#endif /* _CIFS_MD4_H */
+#endif /* __SMB_COMMON_H__ */
--
2.43.0On Thu, Dec 4, 2025 at 2:00 PM <chenxiaosong.chenxiaosong@linux.dev> wrote: > > From: ChenXiaoSong <chenxiaosong@kylinos.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@kylinos.cn>
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@linux.dev> wrote: >> >> From: ChenXiaoSong <chenxiaosong@kylinos.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@kylinos.cn>
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@linux.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@linux.dev> wrote: > >> > >> From: ChenXiaoSong <chenxiaosong@kylinos.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@kylinos.cn> > -- Thanks, Steve
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@linux.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@linux.dev> wrote: >>>> >>>> From: ChenXiaoSong <chenxiaosong@kylinos.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@kylinos.cn> >> > >
On Thu, Dec 4, 2025 at 7:44 PM ChenXiaoSong <chenxiaosong.chenxiaosong@linux.dev> wrote: > > Now, where should common/smb2maperror.c go? Should it be built into both > cifs.ko and ksmbd.ko? > > Thanks, > ChenXiaoSong. I am open to other opinions - especially from Metze and Namjae who are dealing with similar issues in splitting out the RDMA/smbdirect code, but I lean toward (at least for now) just including it in both cifs.ko or ksmbd.ko, or not moving the C code yet (just move to common headers for #defines, inlined functions that are put in headers etc.). I consider moving the common C functions into a common C file used by cifs.ko and ksmbd.ko is lower priority than other cleanup. Do you have a list of all of the (general types of) functions that smb3common.ko could contain? IIRC you mentioned for mapping errors but what other routines could easily make it into this proposed common module with low risk? > > 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@linux.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@linux.dev> wrote: > >>>> > >>>> From: ChenXiaoSong <chenxiaosong@kylinos.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@kylinos.cn> > >> > > > > > -- Thanks, Steve
Alternatively, we could consider placing MD4 into an smb1_common.ko, and creating an smb2_common.ko for the SMB2/3 common code. What do you think? Thanks, ChenXiaoSong. On 12/5/25 09:50, Steve French wrote: > On Thu, Dec 4, 2025 at 7:44 PM ChenXiaoSong > <chenxiaosong.chenxiaosong@linux.dev> wrote: >> >> Now, where should common/smb2maperror.c go? Should it be built into both >> cifs.ko and ksmbd.ko? >> >> Thanks, >> ChenXiaoSong. > > I am open to other opinions - especially from Metze and Namjae who are > dealing with similar issues in splitting out the RDMA/smbdirect code, > but I lean toward (at least for now) just including it in both cifs.ko > or ksmbd.ko, or not moving the C code yet (just move to common headers > for #defines, inlined functions that are put in headers etc.). I > consider moving the common C functions into a common C file used by > cifs.ko and ksmbd.ko is lower priority than other cleanup. > > Do you have a list of all of the (general types of) functions that > smb3common.ko could contain? IIRC you mentioned for mapping errors > but what other routines could easily make it into this proposed common > module with low risk? > >> >> 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@linux.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@linux.dev> wrote: >>>>>> >>>>>> From: ChenXiaoSong <chenxiaosong@kylinos.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@kylinos.cn> >>>> >>> >>> >> > >
MD4 is also used in SMB2_sess_auth_rawntlmssp_authenticate(), so for now we won't move smb2maperror to common/. We can reconsider this in the future when ksmbd actually needs to use smb2maperror. Thanks, ChenXiaoSong. On 12/5/25 10:14, ChenXiaoSong wrote: > Alternatively, we could consider placing MD4 into an smb1_common.ko, and > creating an smb2_common.ko for the SMB2/3 common code. What do you think? > > Thanks, > ChenXiaoSong. > > On 12/5/25 09:50, Steve French wrote: >> On Thu, Dec 4, 2025 at 7:44 PM ChenXiaoSong >> <chenxiaosong.chenxiaosong@linux.dev> wrote: >>> >>> Now, where should common/smb2maperror.c go? Should it be built into both >>> cifs.ko and ksmbd.ko? >>> >>> Thanks, >>> ChenXiaoSong. >> >> I am open to other opinions - especially from Metze and Namjae who are >> dealing with similar issues in splitting out the RDMA/smbdirect code, >> but I lean toward (at least for now) just including it in both cifs.ko >> or ksmbd.ko, or not moving the C code yet (just move to common headers >> for #defines, inlined functions that are put in headers etc.). I >> consider moving the common C functions into a common C file used by >> cifs.ko and ksmbd.ko is lower priority than other cleanup. >> >> Do you have a list of all of the (general types of) functions that >> smb3common.ko could contain? IIRC you mentioned for mapping errors >> but what other routines could easily make it into this proposed common >> module with low risk? >> >>> >>> 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@linux.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@linux.dev> wrote: >>>>>>> >>>>>>> From: ChenXiaoSong <chenxiaosong@kylinos.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@kylinos.cn> >>>>> >>>> >>>> >>> >> >> >
© 2016 - 2025 Red Hat, Inc.