This is an AI-generated review of your patch. The human sending this email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html --- net/rds: Trigger rds_send_ping() more than once This commit ensures rds_send_ping() is triggered after reconnect to properly communicate multipath capabilities, especially after an RDS module reload. It also validates source port modulo during fan-out. > diff --git a/net/rds/send.c b/net/rds/send.c > index 599c2cfb7a1d..68f6b12c60ef 100644 > --- a/net/rds/send.c > +++ b/net/rds/send.c > @@ -1339,6 +1339,24 @@ int rds_sendmsg(struct socket *sock, struct msghdr > *msg, size_t payload_len) > cpath = &conn->c_path[0]; > } > > + /* Check to see if we have talked to this peer before. > + * If not, this means conn->c_npaths will be zero, > + * and we should initiate a connection request to the > + * peer right away. > + */ > + if (conn->c_trans->t_mp_capable && > + !rds_conn_path_up(&conn->c_path[0])) { This isn't a bug, but the comment says "c_npaths will be zero" while the code checks "!rds_conn_path_up()". These conditions are different: c_npaths == 0 means no paths negotiated yet, while !rds_conn_path_up() is true for any state other than RDS_CONN_UP (DOWN, CONNECTING, DISCONNECTING, ERROR, RESETTING). The commit message mentions "after a re-connect to any peer" which aligns with the code, but the comment specifically mentions c_npaths. Should the comment be updated to reflect the actual logic? This was flagged in v1 review: https://lore.kernel.org/netdev/[email protected]/ [ ... ]
