On (03/16/18 15:38), Kirill Tkhai wrote: > > 467fa15356acf by Sowmini Varadhan added NETDEV_UNREGISTER_FINAL dependence > with the commentary: > > /* rds-tcp registers as a pernet subys, so the ->exit will only > * get invoked after network acitivity has quiesced. We need to > * clean up all sockets to quiesce network activity, and use > * the unregistration of the per-net loopback device as a trigger > * to start that cleanup. > */ > > It seems all the protocols pernet subsystems meet this situation, but they > solve it in generic way. What does rds so specific have? The difference with rds is this: most consumers of netns associate a net_device with the netns, and cleanup of the netns state happens as part of the net_device teardown without the constraint above. rds-tcp does has a netns tied to listening socket, not to a specific network interface (net_device) so it registers as a pernet-subsys. But this means that cleanup has to be cone carefully (see comments in net_namespace.h before register_pernet_subsys) For rds-tcp, we need to be able to do the right thing in both of these cases 1. modprobe -r rds-tcp (cleanup of rds-tcp state should happen in every namespace, including init_net) 2. netns delete (rds_tcp.ko should remain loaded for other namespaces) > This commit makes event handler to iterate rds_tcp_conn_list and > kill them. If we change the stage to NETDEV_UNREGISTER, what will change? The above two cases need to work correctly. > Can unregistered loopback device on dead net add new items to rds_tcp_conn_list? > How it's possible? I dont understand the question- no unregistered loopback devices cannot add items. fwiw, I had asked questions about this (netns per net_device vs netns for module) on the netdev list a few years ago, I can try to hunt down that thread for you later (nobody replied to it, but maybe it will help answer your questions). --Sowmini -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
