• Krister Johansen's avatar
    Fix an intermittent pr_emerg warning about lo becoming free. · 7d98a8d2
    Krister Johansen authored
    [ Upstream commit f186ce61 ]
    
    It looks like this:
    
    Message from syslogd@flamingo at Apr 26 00:45:00 ...
     kernel:unregister_netdevice: waiting for lo to become free. Usage count = 4
    
    They seem to coincide with net namespace teardown.
    
    The message is emitted by netdev_wait_allrefs().
    
    Forced a kdump in netdev_run_todo, but found that the refcount on the lo
    device was already 0 at the time we got to the panic.
    
    Used bcc to check the blocking in netdev_run_todo.  The only places
    where we're off cpu there are in the rcu_barrier() and msleep() calls.
    That behavior is expected.  The msleep time coincides with the amount of
    time we spend waiting for the refcount to reach zero; the rcu_barrier()
    wait times are not excessive.
    
    After looking through the list of callbacks that the netdevice notifiers
    invoke in this path, it appears that the dst_dev_event is the most
    interesting.  The dst_ifdown path places a hold on the loopback_dev as
    part of releasing the dev associated with the original dst cache entry.
    Most of our notifier callbacks are straight-forward, but this one a)
    looks complex, and b) places a hold on the network interface in
    question.
    
    I constructed a new bcc script that watches various events in the
    liftime of a dst cache entry.  Note that dst_ifdown will take a hold on
    the loopback device until the invalidated dst entry gets freed.
    
    [      __dst_free] on DST: ffff883ccabb7900 IF tap1008300eth0 invoked at 1282115677036183
        __dst_free
        rcu_nocb_kthread
        kthread
        ret_from_fork
    Acked-by: default avatarEric Dumazet <edumazet@google.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
    7d98a8d2
dst.c 9.99 KB