Daniel Lezcano wrote: > Denis V. Lunev wrote: >> Daniel Lezcano wrote: >>> Hi all, >>> >>> while doing ipv6 namespace, we were faced to a problem with the loopback >>> and the dst_destroy function. >>> >>> When the network namespace exits, the cleanup function is called by >>> schedule_work and this function will browse the net ops list to call the >>> different exit methods for the registered subsystems. >>> >>> The different subsystems will shutdown their resources and in particular >>> addrconf subsystem will ifdown the loopback. This function will call >>> rt6_ifdown >>> -> fib6_clean_all >>> -> fib6_clean_node >>> -> fib6_clean_tree >>> -> fib6_clean_node >>> -> fib6_del >>> -> fib6_del_route >>> -> rt6_release >>> ->dst_free >>> -> __dst_free >>> >>> The __dst_free function will schedule_delayed_work the dst_gc_work >>> function. >>> >>> The dst_gc_work will call dst_destroy and finally this one will call >>> dst->ops->destroy ops function which is ip6_dst_destroy. >>> >>> The problem here is we have the workq blocked because we are running >>> inside the netns cleanup function. So the delayed work will not run >>> until we exits the cleanup function. But the loopback is still >>> referenced by the ip6 routes, the netdev_unregister will loop >>> indefinitly => dead lock. >>> >>> By the way, this bug appears with ipv6 but it is perhaps pending with >>> ipv4. >>> >>> Benjamin as proposed to create a separate workq for the network >>> namespace, so in the worst case we have the unregister looping until the >>> ip6 route are shut downed. Is it an acceptable solution ? >>> >> >> we are doing this staff in the special thread. There are a lot of >> difficult things to perform like synchronize_net & netdev_run_todo inside > > The special thread ? do you mean keventd_wq ? > I mean that network namespace deletion, i.e. all subsystem ->exit calls should be run outside of all current mechanisms in the separate thread, specially designated to namespace(s) stop. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers