Re: [PATCH net-next v2 0/2] net/rds: Bug fix ports, part 2
Simon Horman <[email protected]>
| Newsgroups | org.kernel.vger.netdev,org.kernel.vger.linux-rdma |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Aug 08, 2026 at 05:51:01PM -0700, Allison Henderson wrote:
> Hi all,
>
> This is the next batch of net/rds fixes ported from the Oracle UEK
> kernel, following up on the first set now in net-next [1].
>
> This is v2 of patches 1 and 2 of "net/rds: Bug fix ports, part 2"
> [2], which contained two initialization-hardening ports. While
> re-reviewing v1's patches 3 and 4 (the fastpath-lock teardown changes)
> I found their locking needs more rework than a respin should carry, so
> they are split out and will return as their own series together with
> two companion fixes. The two patches here are independent of them.
>
> [PATCH net 1/2] net/rds: reinitialize to_be_dropped on rds_send_xmit() restart
> Port commit 7f52b9968d79 ("net/rds: rds_send_xmit should INIT_LIST_HEAD (&to_be_dropped) on restart")
> https://github.com/oracle/linux-uek/commit/7f52b9968d79
>
> [PATCH net 2/2] net/rds: initialize i_conn_path in rds_inc_init()
> Port commit 0ec6a520da4f ("rds: rds_inc_init() should initialize the inc->i_conn_path field")
> https://github.com/oracle/linux-uek/commit/0ec6a520da4f
>
> Questions and comments appreciated!
>
> Thanks,
> Allison
>
> v2:
> - Patch 1: the comment now names rds_send_remove_from_sock()
> instead of vaguely blaming "the callees", and the restart-time
> invariant is enforced with a WARN_ON_ONCE(): entries still on
> the list there would keep their message reference and their
> RDS_MSG_ON_SOCK accounting, so a silent re-init would orphan
> them.
> - Patch 2: for loopback the field held a live value written by
> rds_send_queue_rm(), not garbage; rds_loop_xmit() now uses
> rds_inc_path_init() so the re-initialization keeps it valid, and
> the commit message describes the two transports accurately.
>
> [1] https://lore.kernel.org/netdev/[email protected]/
> [2] https://lore.kernel.org/netdev/[email protected]/
For the series:
Reviewed-by: Simon Horman <[email protected]>