Patch "rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete" has been added to the 4.14-stable tree
Subsystems (3)
This is a note to let you know that I've just added the patch titled
rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
rds-tcp-atomically-purge-entries-from-rds_tcp_conn_list-during-netns-delete.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From
f10b4cff98c6977668434fbf5dd58695eeca2897Mon Sep 17 00:00:00 2001
From: Sowmini Varadhan <[email protected]>
Date: Thu, 30 Nov 2017 11:11:29 -0800
Subject: rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete
From: Sowmini Varadhan <[email protected]>
commit f10b4cff98c6977668434fbf5dd58695eeca2897 upstream.
The rds_tcp_kill_sock() function parses the rds_tcp_conn_list to find the rds_connection entries marked for deletion as part of the netns deletion under the protection of the rds_tcp_conn_lock. Since the rds_tcp_conn_list tracks rds_tcp_connections (which have a 1:1 mapping with rds_conn_path), multiple tc entries in the rds_tcp_conn_list will map to a single rds_connection, and will be deleted as part of the rds_conn_destroy() operation that is done outside the rds_tcp_conn_lock.
The rds_tcp_conn_list traversal done under the protection of rds_tcp_conn_lock should not leave any doomed tc entries in the list after the rds_tcp_conn_lock is released, else another concurrently executiong netns delete (for a differnt netns) thread may trip on these entries.
--- net/rds/tcp.c | 9 +++++++-- net/rds/tcp.h | 1 + 2 files changed, 8 insertions(+), 2 deletions(-)
net/rds/tcp.c +7 -2
@@ -306,7 +306,8 @@ static void rds_tcp_conn_free(void *arg)rdsdebug ("freeing tc %p\n" , tc);spin_lock_irqsave (&rds_tcp_conn_lock, flags); -list_del (&tc->t_tcp_node); +if (!tc->t_tcp_node_detached) +list_del (&tc->t_tcp_node);spin_unlock_irqrestore (&rds_tcp_conn_lock, flags);kmem_cache_free (rds_tcp_conn_slab, tc);
@@ -531,8 +532,12 @@ static void rds_tcp_kill_sock(struct netif (net != c_net || !tc->t_sock)continue ; -if (!list_has_conn (&tmp_list, tc->t_cpath->cp_conn)) +if (!list_has_conn (&tmp_list, tc->t_cpath->cp_conn)) {list_move_tail (&tc->t_tcp_node, &tmp_list); + }else { +list_del (&tc->t_tcp_node); + tc->t_tcp_node_detached = true; + } }spin_unlock_irq (&rds_tcp_conn_lock);list_for_each_entry_safe (tc, _tc, &tmp_list, t_tcp_node) {
net/rds/tcp.h +1 -0
@@ -12,6 +12,7 @@ struct rds_tcp_incoming {struct rds_tcp_connection {struct list_head t_tcp_node; +bool t_tcp_node_detached;struct rds_conn_path *t_cpath;/* t_conn_path_lock synchronizes the connection establishment between * rds_tcp_accept_one and rds_tcp_conn_path_connect
Patches currently in stable-queue which might be from [email protected] are
queue-4.14/rds-tcp-atomically-purge-entries-from-rds_tcp_conn_list-during-netns-delete.patch queue-4.14/rds-tcp-correctly-sequence-cleanup-on-netns-deletion.patch