On Tue, Jun 23, 2026 at 2:35 AM Eric Dumazet [off-list ref] wrote:

On Mon, Jun 22, 2026 at 10:37 PM Eric Dumazet [off-list ref] wrote:

quoted

On Mon, Jun 22, 2026 at 6:48 PM Xin Long [off-list ref] wrote:

quoted

quoted

Could this corrupt the list for concurrent RCU readers?
When list_del_rcu() is called, it intentionally leaves the next pointer
intact so concurrent readers can continue their traversal. However, the
immediate call to list_add() overwrites both the next and prev pointers
to link the entry into private_list.
If a concurrent reader is currently positioned at rcast, won't it follow
the newly clobbered next pointer and jump from the original RCU list
directly into private_list?
Because private_list is allocated on the local stack, the reader might
interpret stack memory as a struct udp_replicast. Furthermore, the reader
would miss its loop termination condition because it expects to reach the
original list head, potentially resulting in an infinite loop or a crash.
[ ... ]

I think you are right.

Considering there is already one rcu_head in udp_replicast I will use it in V2.

While looking at many syzbot reports with RTNL pressure. I found this
gem in  tipc_exit_net()

while (atomic_read(&tn->wq_count))
      cond_resched();

On some kernel builds cond_resched() can be a NOP, so we might loop
here for a while :/

True, thanks for the report,

I think a cleanup_wq should be added for 'ub->work' instead of using system_wq,
and then do flush_workqueue(cleanup_wq) in tipc_init_net().

Added in

commit 04c26faa51d1e2fe71cf13c45791f5174c37f986    tipc: wait and exit
until all work queues are done