Re: [PATCH net-next v7 12/12] net/rds: drop rds_conn_count in favor of t_conn_count
flat view
From: netdev-bot+sashiko@kernel.org
Date: 2026-10-01 06:16:16
Also in:
linux-rdma
Thank you for your contribution! Sashiko AI review found more severe issue(s) in other patches of this series. This mail is only an FYI, in case you want to address the nit picks below when you respin. Low priority / nit picks for your consideration: - [Low] The commit message says the wrong patch introduced t_conn_count. -- net/rds: drop rds_conn_count in favor of t_conn_count This commit removes the global rds_conn_count. The per-path workqueue names in __rds_conn_create() now use the per-transport t_conn_count as their seed. It also drops the rds_conn_lock round-trip that rds_conn_destroy_fini() took only to decrement the old counter.
The previous patch gave each transport its own connection count in t_conn_count, incremented and decremented at exactly the points where the global rds_conn_count is.
[Severity: Low] Is "the previous patch" the right reference here? The patch right before this one is "net/rds: pin the connection across RDMA-CM event handling". It does not touch net/rds/connection.c or net/rds/rds.h, and it has nothing to do with t_conn_count. t_conn_count was added earlier in the series by "net/rds: wait for connections to be freed on transport unload". That commit's notes say "t_conn_count did not exist upstream and is introduced here". It also cites the same UEK commit, "net/rds: Each RDS transport should keep its own connection count". Could this sentence name that commit by its subject instead? For example: Commit "net/rds: wait for connections to be freed on transport unload" gave each transport its own connection count in t_conn_count, ... That way the reference still holds if the series is reordered or split when it is applied. The rest of the message matches the code. In the parent tree, rds_conn_count's only reader is the alloc_ordered_workqueue() name seed in __rds_conn_create(). Its increments and decrement sit right next to the t_conn_count ones. -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260927061448.167862-1-achender%40kernel.org