fs/smb/client/Kconfig | 1 + fs/smb/server/Kconfig | 1 + 2 files changed, 2 insertions(+)
From: Arnd Bergmann <arnd@arndb.de>
When CONFIG_INFINIBAND is set to =m, it is not possible to have SMBDIRECT
built-in, and it turns into a loadable module, but this does not prevent
CIFS and SMB_SERVER from being built-in, which in turn causes this
link error:
ld.lld-22: error: undefined symbol: smbdirect_socket_release
>>> referenced by smbdirect.c:212 (fs/smb/client/smbdirect.c:212)
>>> fs/smb/client/smbdirect.o:(smbd_destroy) in archive vmlinux.a
>>> referenced by smbdirect.c:212 (fs/smb/client/smbdirect.c:212)
>>> fs/smb/client/smbdirect.o:(smbd_reconnect) in archive vmlinux.a
>>> referenced by smbdirect.c:338 (fs/smb/client/smbdirect.c:338)
>>> fs/smb/client/smbdirect.o:(smbd_get_connection) in archive vmlinux.a
Enforce the dependency at Kconfig level, so that the respective smpdirect
options are only offered if it's possible to link against the common
module and infiniband.
Fixes: 28504d6ee127 ("smb: client: make use of smbdirect.ko")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
fs/smb/client/Kconfig | 1 +
fs/smb/server/Kconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/fs/smb/client/Kconfig b/fs/smb/client/Kconfig
index 72f47669da0c..981b3b5be09b 100644
--- a/fs/smb/client/Kconfig
+++ b/fs/smb/client/Kconfig
@@ -182,6 +182,7 @@ if CIFS
config CIFS_SMB_DIRECT
bool "SMB Direct support"
depends on CIFS && INFINIBAND && INFINIBAND_ADDR_TRANS
+ depends on CIFS=m || INFINIBAND=y
select SMB_COMMON_SMBDIRECT
help
Enables SMB Direct support for SMB 3.0, 3.02 and 3.1.1.
diff --git a/fs/smb/server/Kconfig b/fs/smb/server/Kconfig
index b084071d2442..5c77c5552ed8 100644
--- a/fs/smb/server/Kconfig
+++ b/fs/smb/server/Kconfig
@@ -49,6 +49,7 @@ if SMB_SERVER
config SMB_SERVER_SMBDIRECT
bool "Support for SMB Direct protocol"
depends on SMB_SERVER && INFINIBAND && INFINIBAND_ADDR_TRANS
+ depends on SMB_SERVER=m || INFINIBAND=y
select SMB_COMMON_SMBDIRECT
default n
--
2.39.5
On Fri, Mar 6, 2026 at 11:44 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> When CONFIG_INFINIBAND is set to =m, it is not possible to have SMBDIRECT
> built-in, and it turns into a loadable module, but this does not prevent
> CIFS and SMB_SERVER from being built-in, which in turn causes this
> link error:
>
> ld.lld-22: error: undefined symbol: smbdirect_socket_release
> >>> referenced by smbdirect.c:212 (fs/smb/client/smbdirect.c:212)
> >>> fs/smb/client/smbdirect.o:(smbd_destroy) in archive vmlinux.a
> >>> referenced by smbdirect.c:212 (fs/smb/client/smbdirect.c:212)
> >>> fs/smb/client/smbdirect.o:(smbd_reconnect) in archive vmlinux.a
> >>> referenced by smbdirect.c:338 (fs/smb/client/smbdirect.c:338)
> >>> fs/smb/client/smbdirect.o:(smbd_get_connection) in archive vmlinux.a
>
> Enforce the dependency at Kconfig level, so that the respective smpdirect
> options are only offered if it's possible to link against the common
> module and infiniband.
>
> Fixes: 28504d6ee127 ("smb: client: make use of smbdirect.ko")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Thanks!
Hi Arnd,
> When CONFIG_INFINIBAND is set to =m, it is not possible to have SMBDIRECT
> built-in, and it turns into a loadable module, but this does not prevent
> CIFS and SMB_SERVER from being built-in, which in turn causes this
> link error:
>
> ld.lld-22: error: undefined symbol: smbdirect_socket_release
>>>> referenced by smbdirect.c:212 (fs/smb/client/smbdirect.c:212)
>>>> fs/smb/client/smbdirect.o:(smbd_destroy) in archive vmlinux.a
>>>> referenced by smbdirect.c:212 (fs/smb/client/smbdirect.c:212)
>>>> fs/smb/client/smbdirect.o:(smbd_reconnect) in archive vmlinux.a
>>>> referenced by smbdirect.c:338 (fs/smb/client/smbdirect.c:338)
>>>> fs/smb/client/smbdirect.o:(smbd_get_connection) in archive vmlinux.a
>
> Enforce the dependency at Kconfig level, so that the respective smpdirect
> options are only offered if it's possible to link against the common
> module and infiniband.
>
> Fixes: 28504d6ee127 ("smb: client: make use of smbdirect.ko")
Thanks for the fix!
Steve can you put that an top of ksmbd-for-next for the moment.
Then I'll squash the hunks in the correct patch and provide
a new branch, as the 2nd would have:
Fixes: 30807ad55601 ("smb: server: make use of smbdirect.ko")
But both hashes are unlikely be the ones landing upstream,
so as we do rebase anyway I'd squash them, but maybe
I'll have time for the rebase after -rc4.
So we should take it as is for now, but maybe without the
Fixes tag, but acked by me.
Thanks!
metze
added the acked-by and merged into ksmbd-for-next
On Fri, Mar 6, 2026 at 9:30 AM Stefan Metzmacher via samba-technical
<samba-technical@lists.samba.org> wrote:
>
> Hi Arnd,
>
> > When CONFIG_INFINIBAND is set to =m, it is not possible to have SMBDIRECT
> > built-in, and it turns into a loadable module, but this does not prevent
> > CIFS and SMB_SERVER from being built-in, which in turn causes this
> > link error:
> >
> > ld.lld-22: error: undefined symbol: smbdirect_socket_release
> >>>> referenced by smbdirect.c:212 (fs/smb/client/smbdirect.c:212)
> >>>> fs/smb/client/smbdirect.o:(smbd_destroy) in archive vmlinux.a
> >>>> referenced by smbdirect.c:212 (fs/smb/client/smbdirect.c:212)
> >>>> fs/smb/client/smbdirect.o:(smbd_reconnect) in archive vmlinux.a
> >>>> referenced by smbdirect.c:338 (fs/smb/client/smbdirect.c:338)
> >>>> fs/smb/client/smbdirect.o:(smbd_get_connection) in archive vmlinux.a
> >
> > Enforce the dependency at Kconfig level, so that the respective smpdirect
> > options are only offered if it's possible to link against the common
> > module and infiniband.
> >
> > Fixes: 28504d6ee127 ("smb: client: make use of smbdirect.ko")
>
> Thanks for the fix!
>
> Steve can you put that an top of ksmbd-for-next for the moment.
> Then I'll squash the hunks in the correct patch and provide
> a new branch, as the 2nd would have:
>
> Fixes: 30807ad55601 ("smb: server: make use of smbdirect.ko")
>
> But both hashes are unlikely be the ones landing upstream,
> so as we do rebase anyway I'd squash them, but maybe
> I'll have time for the rebase after -rc4.
>
> So we should take it as is for now, but maybe without the
> Fixes tag, but acked by me.
>
> Thanks!
> metze
>
--
Thanks,
Steve
© 2016 - 2026 Red Hat, Inc.