• Xin Long's avatar
    tipc: change to use register_pernet_device · c492d4c7
    Xin Long authored
    This patch is to fix a dst defcnt leak, which can be reproduced by doing:
    
      # ip net a c; ip net a s; modprobe tipc
      # ip net e s ip l a n eth1 type veth peer n eth1 netns c
      # ip net e c ip l s lo up; ip net e c ip l s eth1 up
      # ip net e s ip l s lo up; ip net e s ip l s eth1 up
      # ip net e c ip a a 1.1.1.2/8 dev eth1
      # ip net e s ip a a 1.1.1.1/8 dev eth1
      # ip net e c tipc b e m udp n u1 localip 1.1.1.2
      # ip net e s tipc b e m udp n u1 localip 1.1.1.1
      # ip net d c; ip net d s; rmmod tipc
    
    and it will get stuck and keep logging the error:
    
      unregister_netdevice: waiting for lo to become free. Usage count = 1
    
    The cause is that a dst is held by the udp sock's sk_rx_dst set on udp rx
    path with udp_early_demux == 1, and this dst (eventually holding lo dev)
    can't be released as bearer's removal in tipc pernet .exit happens after
    lo dev's removal, default_device pernet .exit.
    
     "There are two distinct types of pernet_operations recognized: subsys and
      device.  At creation all subsys init functions are called before device
      init functions, and at destruction all device exit functions are called
      before subsys exit function."
    
    So by calling register_pernet_device instead to register tipc_net_ops, the
    pernet .exit() will be invoked earlier than loopback dev's removal when a
    netns is being destroyed, as fou/gue does.
    
    Note that vxlan and geneve udp tunnels don't have this issue, as the udp
    sock is released in their device ndo_stop().
    
    This fix is also necessary for tipc dst_cache, which will hold dsts on tx
    path and I will introduce in my next patch.
    Reported-by: default avatarLi Shuang <shuali@redhat.com>
    Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
    Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    c492d4c7
core.c 4.95 KB