Re: [PATCH net] net/rds: use wq_has_sleeper() in rds_cong_map_updated()
Simon Horman <[email protected]>
| Newsgroups | org.kernel.vger.linux-rdma,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Aug 21, 2026 at 10:26:47PM -0700, Allison Henderson wrote:
> rds_cong_map_updated() runs after a peer's congestion map has been
> rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the
> clear-all in the loopback and IB send-completion paths). It bumps
> rds_cong_generation and then checks waitqueue_active() on
> map->m_waitq and on rds_poll_waitq to decide whether anyone needs
> waking. atomic_inc() carries no ordering and waitqueue_active() is a
> plain load, so nothing orders the map and generation stores before
> the wait queue reads. The waiters do the mirror image: rds_cong_wait()
> adds itself to m_waitq and then tests the port bit, and rds_poll()
> registers on rds_poll_waitq and then reads the generation. That is
> the store-buffering pattern described above waitqueue_active() in
> include/linux/wait.h - the updater can observe an empty wait queue
> while the waiter still observes the port as congested, and no wake-up
> is issued.
>
> rds_cong_wait() is an interruptible sleep with no timeout, so a
> sender blocked on a congested port stays blocked until the next
> congestion update from that peer arrives or a signal is delivered.
> A poll() waiter misses the map-updated notification the same way.
>
> Use wq_has_sleeper(), which is waitqueue_active() preceded by the
> required full barrier, as rds_tcp_state_change() already does for
> the same pattern.
>
> Fixes: 922cb17a5c81 ("RDS: Congestion-handling code")
> Assisted-by: Claude-Code:claude-fable-5
> Signed-off-by: Allison Henderson <[email protected]>
> ---
> Raised during review of "net/rds: own the fastpath locks across
> connection teardown", whose first patch fixes the same pattern in
> release_in_xmit():
> https://lore.kernel.org/netdev/[email protected]/
> This patch is independent of that set and applies on its own.
Reviewed-by: Simon Horman <[email protected]>