Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree

[Zhu Yanjun <yanjun.zhu@linux.dev>]

Hi, Stephen

I am the author of the commit 8ce2eb9dfac8 ("RDMA/rxe: Fix the failure 
of ibv_query_device() and ibv_query_device_ex() tests").

My replies are inline. Thanks a lot.

"

diff --cc drivers/infiniband/sw/rxe/rxe.c
index e27478fe9456,4e56a371deb5..000000000000
--- a/drivers/infiniband/sw/rxe/rxe.c
+++ b/drivers/infiniband/sw/rxe/rxe.c
@@@ -72,10 -71,45 +69,39 @@@ static void rxe_init_device_param(struc
       rxe->attr.max_pkeys            = RXE_MAX_PKEYS;
       rxe->attr.local_ca_ack_delay        = RXE_LOCAL_CA_ACK_DELAY;

  -    ndev = rxe_ib_device_get_netdev(&rxe->ib_dev);
  -    if (!ndev)
  -        return;
  -
+     if (ndev->addr_len) {
+         memcpy(rxe->raw_gid, ndev->dev_addr,
+             min_t(unsigned int, ndev->addr_len, ETH_ALEN));
+     } else {
+         /*
+          * This device does not have a HW address, but
+          * connection mangagement requires a unique gid.
+          */
+         eth_random_addr(rxe->raw_gid);
+     }
+
       addrconf_addr_eui48((unsigned char *)&rxe->attr.sys_image_guid,
-             ndev->dev_addr);
+             rxe->raw_gid);

  -    dev_put(ndev);
  -


------The above snippet is fine with me.


       rxe->max_ucontext            = RXE_MAX_UCONTEXT;
+
+     if (IS_ENABLED(CONFIG_INFINIBAND_ON_DEMAND_PAGING)) {
+         rxe->attr.kernel_cap_flags |= IBK_ON_DEMAND_PAGING;
+
+         /* IB_ODP_SUPPORT_IMPLICIT is not supported right now. */
+         rxe->attr.odp_caps.general_caps |= IB_ODP_SUPPORT;
+
+         rxe->attr.odp_caps.per_transport_caps.ud_odp_caps |= 
IB_ODP_SUPPORT_SEND;
+         rxe->attr.odp_caps.per_transport_caps.ud_odp_caps |= 
IB_ODP_SUPPORT_RECV;
+         rxe->attr.odp_caps.per_transport_caps.ud_odp_caps |= 
IB_ODP_SUPPORT_SRQ_RECV;
+
+         rxe->attr.odp_caps.per_transport_caps.rc_odp_caps |= 
IB_ODP_SUPPORT_SEND;
+         rxe->attr.odp_caps.per_transport_caps.rc_odp_caps |= 
IB_ODP_SUPPORT_RECV;
+         rxe->attr.odp_caps.per_transport_caps.rc_odp_caps |= 
IB_ODP_SUPPORT_WRITE;
+         rxe->attr.odp_caps.per_transport_caps.rc_odp_caps |= 
IB_ODP_SUPPORT_READ;
+         rxe->attr.odp_caps.per_transport_caps.rc_odp_caps |= 
IB_ODP_SUPPORT_ATOMIC;
+         rxe->attr.odp_caps.per_transport_caps.rc_odp_caps |= 
IB_ODP_SUPPORT_SRQ_RECV;
+     }
   }



---------The above snippet is from on_demand paging commits. I do not 
why it is involved in this commit.

---------It should appear in on_demand_paging patchset.


   /* initialize port attributes */
@@@ -107,13 -141,18 +133,13 @@@ static void rxe_init_port_param(struct
   /* initialize port state, note IB convention that HCA ports are always
    * numbered from 1
    */
  -static void rxe_init_ports(struct rxe_dev *rxe)
  +static void rxe_init_ports(struct rxe_dev *rxe, struct net_device *ndev)


----------In this snippet, the variable "struct net_device *ndev" is not 
used in the function rxe_init_ports, it should be removed.

----------Thanks a lot.

Zhu Yanjun


   {
       struct rxe_port *port = &rxe->port;
  -    struct net_device *ndev;

       rxe_init_port_param(port);
  -    ndev = rxe_ib_device_get_netdev(&rxe->ib_dev);
  -    if (!ndev)
  -        return;
       addrconf_addr_eui48((unsigned char *)&port->port_guid,
-                 ndev->dev_addr);
+                 rxe->raw_gid);
  -    dev_put(ndev);
       spin_lock_init(&port->port_lock);
   }

"

On 06.03.25 02:37, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
>    drivers/infiniband/sw/rxe/rxe.c
>
> between commit:
>
>    8ce2eb9dfac8 ("RDMA/rxe: Fix the failure of ibv_query_device() and ibv_query_device_ex() tests")
>
> from the rdma-fixes tree and commit:
>
>    d34d0bdb500e ("RDMA/rxe: Replace netdev dev addr with raw_gid")
>
> from the rdma tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
-- 
Best Regards,
Yanjun.Zhu