Re: [RFC PATCH 0/3] RDMA/smbdirect: introduce and use rdma_restrict_node_type()

[Leon Romanovsky <leon@kernel.org>]

On Tue, Feb 03, 2026 at 11:37:42AM -0600, Steve French wrote:
> On Tue, Feb 3, 2026 at 9:25 AM Stefan Metzmacher <metze@samba.org> wrote:
> >
> > Am 28.01.26 um 15:11 schrieb Leon Romanovsky:
> > > On Wed, Jan 21, 2026 at 09:07:10PM +0100, Stefan Metzmacher wrote:
> > >> Hi,
> > >>
> > >> for smbdirect it required to use different ports depending
> > >> on the RDMA protocol. E.g. for iWarp 5445 is needed
> > >> (as tcp port 445 already used by the raw tcp transport for SMB),
> > >> while InfiniBand, RoCEv1 and RoCEv2 use port 445, as they
> > >> use an independent port range (even for RoCEv2, which uses udp
> > >> port 4791 itself).
> > >>
> > >> Currently ksmbd is not able to function correctly at
> > >> all if the system has iWarp (RDMA_NODE_RNIC) interface(s)
> > >> and any InfiniBand, RoCEv1 and/or RoCEv2 interface(s)
> > >> at the same time.
> > >>
> > >> And cifs.ko uses 5445 with a fallback to 445, which
> > >> means depending on the available interfaces, it tries
> > >> 5445 in the RoCE range or may tries iWarp with 445
> > >> as a fallback. This leads to strange error messages
> > >> and strange network captures.
> > >>
> > >> To avoid these problems they will be able to
> > >> use rdma_restrict_node_type(RDMA_NODE_RNIC) before
> > >> trying port 5445 and rdma_restrict_node_type(RDMA_NODE_IB_CA)
> > >> before trying port 445. It means we'll get early
> > >> -ENODEV early from rdma_resolve_addr() without any
> > >> network traffic and timeouts.
> > >>
> > >> This is marked as RFC as I want to get feedback
> > >> if the rdma_restrict_node_type() function is acceptable
> > >> for the RDMA layer. And because the current form of
> > >> the smb patches are not tested, I only tested the
> > >> rdma part with my branch the prepares IPPROTO_SMBDIRECT
> > >> sockets.
> > >>
> > >> I'm not sure if this would be acceptable for 6.19
> > >> in order to avoid the smb layer problems, if the
> > >> RDMA layer change is only acceptable for 7.0 that's
> > >> also fine.
> > >>
> > >> This is based on the following fix applied:
> > >> smb: server: reset smb_direct_port = SMB_DIRECT_PORT_INFINIBAND on init
> > >> https://lore.kernel.org/linux-cifs/20251208154919.934760-1-metze@samba.org/
> > >> It's not yet in Linus' tree, so if this gets ready
> > >> before it's merged we can squash it.
> > >>
> > >> Stefan Metzmacher (3):
> > >>    RDMA/core: introduce rdma_restrict_node_type()
> > >>    smb: client: make use of rdma_restrict_node_type()
> > >>    smb: server: make use of rdma_restrict_node_type()
> > >
> > > The approach looks reasonable.
> >
> > Thanks!
> >
> > > Do you want me to take it through RDMA
> > > tree?
> >
> > As I also have other smb patches on top changing/using
> > it I guess it would be easier if Steve would take them.
> >
> > Steve, Leon what do you think?
> 
> I am ok with taking it via the ksmbd tree (smb3-kernel ksmbd-for-next
> branch), unless it is practical to merge the RDMA changes through the
> RDMA tree in the first few days of the merge window and merge the
> ksmbd-for-next branch a few days later (which sounds potentially
> trickier)

The latter is a common merge workflow used to avoid merge conflicts, but it
is not needed here. There are no changes in the rdma-cm area for this cycle,
so I do not expect any merge conflicts during the final days of the cycle.

Thanks

> 
> 
> -- 
> Thanks,
> 
> Steve
>