[PATCH 1/2] drbd: fix rdma dependency
Christoph Böhmwalder
christoph.boehmwalder at linbit.com
Wed Mar 18 16:36:32 CET 2026
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
More information about the drbd-dev
mailing list