[PATCH 1/2] drbd: fix rdma dependency

[PATCH 1/2] drbd: fix rdma dependency

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

The new rdma transport module uses a trick to only build support
if infiniband/rdma is enabled. This seems to be done the wrong way
around, as it gets built if RDMA is in a loadable module, but not
if it's built-in.

However, this fails in configurations that have infiniband support
in a loadable module but drbd built-in:

ERROR: modpost: "rdma_bind_addr" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
ERROR: modpost: "rdma_listen" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
ERROR: modpost: "rdma_destroy_id" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
ERROR: modpost: "rdma_destroy_qp" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
ERROR: modpost: "rdma_disconnect" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
ERROR: modpost: "__rdma_create_kernel_id" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
ERROR: modpost: "rdma_resolve_route" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
ERROR: modpost: "rdma_reject" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
ERROR: modpost: "rdma_accept" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
ERROR: modpost: "rdma_create_qp" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!

Address this by moving the logic from Makefile into Kconfig and
describing the two conditions in which rdma transport can be used
in drbd.

Fixes: 038cb6e644e4 ("drbd: add RDMA transport implementation")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/block/drbd/Kconfig  | 5 +++++
 drivers/block/drbd/Makefile | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/block/drbd/Kconfig b/drivers/block/drbd/Kconfig
index 377f0d040031..29ec6ed84251 100644
--- a/drivers/block/drbd/Kconfig
+++ b/drivers/block/drbd/Kconfig
@@ -39,6 +39,11 @@ config BLK_DEV_DRBD
 
 	  If unsure, say N.
 
+config DRBD_TRANSPORT_RDMA
+	tristate
+	depends on RDMA=y || (BLK_DEV_DRBD=RDMA)
+	default BLK_DEV_DRBD
+
 config DRBD_FAULT_INJECTION
 	bool "DRBD fault injection"
 	depends on BLK_DEV_DRBD
diff --git a/drivers/block/drbd/Makefile b/drivers/block/drbd/Makefile
index 99a1cfeed423..caf888235d53 100644
--- a/drivers/block/drbd/Makefile
+++ b/drivers/block/drbd/Makefile
@@ -13,4 +13,4 @@ obj-$(CONFIG_BLK_DEV_DRBD)     += drbd.o
 
 obj-$(CONFIG_BLK_DEV_DRBD)     += drbd_transport_tcp.o
 obj-$(CONFIG_BLK_DEV_DRBD)     += drbd_transport_lb-tcp.o
-obj-$(if $(CONFIG_BLK_DEV_DRBD),$(if $(CONFIG_INFINIBAND),m)) += drbd_transport_rdma.o
+obj-$(CONFIG_DRBD_TRANSPORT_RDMA) += drbd_transport_rdma.o
-- 
2.39.5

[PATCH 2/2] drbd: select CONFIG_NET_HANDSHAKE

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

The TLS handshake code is optional and has to be enabled for DRBD:

ERROR: modpost: "tls_handshake_cancel" [drivers/block/drbd/drbd_transport_tcp.ko] undefined!
ERROR: modpost: "tls_server_hello_x509" [drivers/block/drbd/drbd_transport_tcp.ko] undefined!
ERROR: modpost: "tls_client_hello_x509" [drivers/block/drbd/drbd_transport_tcp.ko] undefined!
ERROR: modpost: "tls_get_record_type" [drivers/block/drbd/drbd_transport_tcp.ko] undefined!
ERROR: modpost: "tls_alert_recv" [drivers/block/drbd/drbd_transport_tcp.ko] undefined!

Select the option whenever DRBD is eanbled and rework the dependency in
the symbol so it can be selected more easily.

Fixes: fa8ef6960ebd ("drbd: add TCP transport implementation")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/block/drbd/Kconfig | 1 +
 net/Kconfig                | 4 +---
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/block/drbd/Kconfig b/drivers/block/drbd/Kconfig
index 29ec6ed84251..de9e232d6479 100644
--- a/drivers/block/drbd/Kconfig
+++ b/drivers/block/drbd/Kconfig
@@ -11,6 +11,7 @@ config BLK_DEV_DRBD
 	depends on PROC_FS && INET
 	select LRU_CACHE
 	select CRC32
+	select NET_HANDSHAKE
 	help
 
 	  NOTE: In order to authenticate connections you have to select
diff --git a/net/Kconfig b/net/Kconfig
index 62266eaf0e95..769880113740 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -92,9 +92,7 @@ source "drivers/dibs/Kconfig"
 source "net/xdp/Kconfig"
 
 config NET_HANDSHAKE
-	bool
-	depends on SUNRPC || NVME_TARGET_TCP || NVME_TCP
-	default y
+	def_bool SUNRPC || NVME_TARGET_TCP || NVME_TCP
 
 config NET_HANDSHAKE_KUNIT_TEST
 	tristate "KUnit tests for the handshake upcall mechanism" if !KUNIT_ALL_TESTS
-- 
2.39.5

Re: [PATCH 2/2] drbd: select CONFIG_NET_HANDSHAKE

[Christoph Böhmwalder]

Am 18.03.26 um 11:48 schrieb Arnd Bergmann:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> The TLS handshake code is optional and has to be enabled for DRBD:
> 
> ERROR: modpost: "tls_handshake_cancel" [drivers/block/drbd/drbd_transport_tcp.ko] undefined!
> ERROR: modpost: "tls_server_hello_x509" [drivers/block/drbd/drbd_transport_tcp.ko] undefined!
> ERROR: modpost: "tls_client_hello_x509" [drivers/block/drbd/drbd_transport_tcp.ko] undefined!
> ERROR: modpost: "tls_get_record_type" [drivers/block/drbd/drbd_transport_tcp.ko] undefined!
> ERROR: modpost: "tls_alert_recv" [drivers/block/drbd/drbd_transport_tcp.ko] undefined!
> 
> Select the option whenever DRBD is eanbled and rework the dependency in
> the symbol so it can be selected more easily.
> 
> Fixes: fa8ef6960ebd ("drbd: add TCP transport implementation")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/block/drbd/Kconfig | 1 +
>  net/Kconfig                | 4 +---
>  2 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/block/drbd/Kconfig b/drivers/block/drbd/Kconfig
> index 29ec6ed84251..de9e232d6479 100644
> --- a/drivers/block/drbd/Kconfig
> +++ b/drivers/block/drbd/Kconfig
> @@ -11,6 +11,7 @@ config BLK_DEV_DRBD
>  	depends on PROC_FS && INET
>  	select LRU_CACHE
>  	select CRC32
> +	select NET_HANDSHAKE
>  	help
>  
>  	  NOTE: In order to authenticate connections you have to select
> diff --git a/net/Kconfig b/net/Kconfig
> index 62266eaf0e95..769880113740 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -92,9 +92,7 @@ source "drivers/dibs/Kconfig"
>  source "net/xdp/Kconfig"
>  
>  config NET_HANDSHAKE
> -	bool
> -	depends on SUNRPC || NVME_TARGET_TCP || NVME_TCP
> -	default y
> +	def_bool SUNRPC || NVME_TARGET_TCP || NVME_TCP
>  
>  config NET_HANDSHAKE_KUNIT_TEST
>  	tristate "KUnit tests for the handshake upcall mechanism" if !KUNIT_ALL_TESTS

Thanks for the fix, I applied it to our drbd-next tree (which should end
up in linux-next).

I would prefer to squash these kinds of fixups to keep the history in
our patch series clean.
Arnd, does that work for you? How do you prefer we handle attribution?

Unfortunately I couldn't really find a clear precedence pattern for
this, how is this usually handled?

-- 
Christoph Böhmwalder
LINBIT | Keeping the Digital World Running
DRBD HA —  Disaster Recovery — Software defined Storage

Re: [PATCH 2/2] drbd: select CONFIG_NET_HANDSHAKE

[Arnd Bergmann]

On Wed, Mar 18, 2026, at 22:16, Christoph Böhmwalder wrote:
> Am 18.03.26 um 11:48 schrieb Arnd Bergmann:

>>  config NET_HANDSHAKE_KUNIT_TEST
>>  	tristate "KUnit tests for the handshake upcall mechanism" if !KUNIT_ALL_TESTS
>
> Thanks for the fix, I applied it to our drbd-next tree (which should end
> up in linux-next).
>
> I would prefer to squash these kinds of fixups to keep the history in
> our patch series clean.
> Arnd, does that work for you? How do you prefer we handle attribution?
>
> Unfortunately I couldn't really find a clear precedence pattern for
> this, how is this usually handled?

Whichever way works best for you. Some people care a lot about 
attribution for bugfixes, but I generally prefer a clean history
myself.

     Arnd

Re: [PATCH 1/2] drbd: fix rdma dependency

[Christoph Böhmwalder]

Am 18.03.26 um 11:48 schrieb Arnd Bergmann:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> The new rdma transport module uses a trick to only build support
> if infiniband/rdma is enabled. This seems to be done the wrong way
> around, as it gets built if RDMA is in a loadable module, but not
> if it's built-in.
> 
> However, this fails in configurations that have infiniband support
> in a loadable module but drbd built-in:
> 
> ERROR: modpost: "rdma_bind_addr" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
> ERROR: modpost: "rdma_listen" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
> ERROR: modpost: "rdma_destroy_id" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
> ERROR: modpost: "rdma_destroy_qp" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
> ERROR: modpost: "rdma_disconnect" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
> ERROR: modpost: "__rdma_create_kernel_id" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
> ERROR: modpost: "rdma_resolve_route" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
> ERROR: modpost: "rdma_reject" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
> ERROR: modpost: "rdma_accept" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
> ERROR: modpost: "rdma_create_qp" [drivers/block/drbd/drbd_transport_rdma.ko] undefined!
> 
> Address this by moving the logic from Makefile into Kconfig and
> describing the two conditions in which rdma transport can be used
> in drbd.
> 
> Fixes: 038cb6e644e4 ("drbd: add RDMA transport implementation")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/block/drbd/Kconfig  | 5 +++++
>  drivers/block/drbd/Makefile | 2 +-
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/block/drbd/Kconfig b/drivers/block/drbd/Kconfig
> index 377f0d040031..29ec6ed84251 100644
> --- a/drivers/block/drbd/Kconfig
> +++ b/drivers/block/drbd/Kconfig
> @@ -39,6 +39,11 @@ config BLK_DEV_DRBD
>  
>  	  If unsure, say N.
>  
> +config DRBD_TRANSPORT_RDMA
> +	tristate
> +	depends on RDMA=y || (BLK_DEV_DRBD=RDMA)
> +	default BLK_DEV_DRBD
> +
>  config DRBD_FAULT_INJECTION
>  	bool "DRBD fault injection"
>  	depends on BLK_DEV_DRBD
> diff --git a/drivers/block/drbd/Makefile b/drivers/block/drbd/Makefile
> index 99a1cfeed423..caf888235d53 100644
> --- a/drivers/block/drbd/Makefile
> +++ b/drivers/block/drbd/Makefile
> @@ -13,4 +13,4 @@ obj-$(CONFIG_BLK_DEV_DRBD)     += drbd.o
>  
>  obj-$(CONFIG_BLK_DEV_DRBD)     += drbd_transport_tcp.o
>  obj-$(CONFIG_BLK_DEV_DRBD)     += drbd_transport_lb-tcp.o
> -obj-$(if $(CONFIG_BLK_DEV_DRBD),$(if $(CONFIG_INFINIBAND),m)) += drbd_transport_rdma.o
> +obj-$(CONFIG_DRBD_TRANSPORT_RDMA) += drbd_transport_rdma.o

Seems like we raced here, I already (supposedly?) fixed this on the
drbd-next branch.

My fix is this Kconfig:

config BLK_DEV_DRBD_RDMA
	tristate "DRBD RDMA transport"
	depends on BLK_DEV_DRBD && INFINIBAND_ADDR_TRANS
	help

	  RDMA transport support for DRBD. This enables DRBD replication
	  over RDMA-capable networks for lower latency and higher throughput.

	  If unsure, say N.

And then just this in the Makefile:

obj-$(CONFIG_BLK_DEV_DRBD_RDMA) += drbd_transport_rdma.o

That should be equivalent, right?

Thanks,
Christoph

-- 
Christoph Böhmwalder
LINBIT | Keeping the Digital World Running
DRBD HA —  Disaster Recovery — Software defined Storage

Re: [PATCH 1/2] drbd: fix rdma dependency

[Arnd Bergmann]

On Wed, Mar 18, 2026, at 16:24, Christoph Böhmwalder wrote:
> Am 18.03.26 um 11:48 schrieb Arnd Bergmann:
>
> Seems like we raced here, I already (supposedly?) fixed this on the
> drbd-next branch.

Ok, I assume that will be in linux-next

> My fix is this Kconfig:
>
> config BLK_DEV_DRBD_RDMA
> 	tristate "DRBD RDMA transport"
> 	depends on BLK_DEV_DRBD && INFINIBAND_ADDR_TRANS
> 	help
>
> 	  RDMA transport support for DRBD. This enables DRBD replication
> 	  over RDMA-capable networks for lower latency and higher throughput.
>
> 	  If unsure, say N.
>
> And then just this in the Makefile:
>
> obj-$(CONFIG_BLK_DEV_DRBD_RDMA) += drbd_transport_rdma.o
>
> That should be equivalent, right?

It's close but not the same: 

- INFINIBAND_ADDR_TRANS is a 'bool' symbol that can still be =y
  when CONFIG_INFINIBAND=m, so you'd still fail to build
  BLK_DEV_DRBD_RDMA. You still need a dependency on INFINIBAND
  (the tristate symbol) itself, though you probably also
  need the INFINIBAND_ADDR_TRANS one that I missed

- I incorrectly assumed from the earlier Makefile logic
  that the rdma transport exports symbols that are used
  by the common drbd code, but I now see that the opposite
  is the case. The difference is that for the case of
  BLK_DEV_DRBD=y, CONFIG_INFINIBAND=m, my version force-disabled
  the RDMA transport, while it should be in a loadable module.

It seems both versions are wrong then, but just adding
'depends on INFINIBAND' on top of yours should fix it.

        Arnd

Re: [PATCH 1/2] drbd: fix rdma dependency

[Christoph Böhmwalder]

Am 18.03.26 um 16:31 schrieb Arnd Bergmann:
> On Wed, Mar 18, 2026, at 16:24, Christoph Böhmwalder wrote:
>> Am 18.03.26 um 11:48 schrieb Arnd Bergmann:
>>
>> Seems like we raced here, I already (supposedly?) fixed this on the
>> drbd-next branch.
> 
> Ok, I assume that will be in linux-next

Correct, should land there today.

> 
>> My fix is this Kconfig:
>>
>> config BLK_DEV_DRBD_RDMA
>> 	tristate "DRBD RDMA transport"
>> 	depends on BLK_DEV_DRBD && INFINIBAND_ADDR_TRANS
>> 	help
>>
>> 	  RDMA transport support for DRBD. This enables DRBD replication
>> 	  over RDMA-capable networks for lower latency and higher throughput.
>>
>> 	  If unsure, say N.
>>
>> And then just this in the Makefile:
>>
>> obj-$(CONFIG_BLK_DEV_DRBD_RDMA) += drbd_transport_rdma.o
>>
>> That should be equivalent, right?
> 
> It's close but not the same: 
> 
> - INFINIBAND_ADDR_TRANS is a 'bool' symbol that can still be =y
>   when CONFIG_INFINIBAND=m, so you'd still fail to build
>   BLK_DEV_DRBD_RDMA. You still need a dependency on INFINIBAND
>   (the tristate symbol) itself, though you probably also
>   need the INFINIBAND_ADDR_TRANS one that I missed
> 
> - I incorrectly assumed from the earlier Makefile logic
>   that the rdma transport exports symbols that are used
>   by the common drbd code, but I now see that the opposite
>   is the case. The difference is that for the case of
>   BLK_DEV_DRBD=y, CONFIG_INFINIBAND=m, my version force-disabled
>   the RDMA transport, while it should be in a loadable module.
> 
> It seems both versions are wrong then, but just adding
> 'depends on INFINIBAND' on top of yours should fix it.

Yes, ADDR_TRANS is needed because we need the infiniband "cm"
infrastructure (for rdma_connect et al).
Right, I did not catch that we need CONFIG_INFINIBAND separately as
well, but that seems logical.
I applied the combined fix now.

Thanks,
Christoph

-- 
Christoph Böhmwalder
LINBIT | Keeping the Digital World Running
DRBD HA —  Disaster Recovery — Software defined Storage