Skip to content
  • Neil Horman's avatar
    ipv4 routing: Ensure that route cache entries are usable and reclaimable with caching is off · b6280b47
    Neil Horman authored
    
    
    When route caching is disabled (rt_caching returns false), We still use route
    cache entries that are created and passed into rt_intern_hash once.  These
    routes need to be made usable for the one call path that holds a reference to
    them, and they need to be reclaimed when they're finished with their use.  To be
    made usable, they need to be associated with a neighbor table entry (which they
    currently are not), otherwise iproute_finish2 just discards the packet, since we
    don't know which L2 peer to send the packet to.  To do this binding, we need to
    follow the path a bit higher up in rt_intern_hash, which calls
    arp_bind_neighbour, but not assign the route entry to the hash table.
    Currently, if caching is off, we simply assign the route to the rp pointer and
    are reutrn success.  This patch associates us with a neighbor entry first.
    
    Secondly, we need to make sure that any single use routes like this are known to
    the garbage collector when caching is off.  If caching is off, and we try to
    hash in a route, it will leak when its refcount reaches zero.  To avoid this,
    this patch calls rt_free on the route cache entry passed into rt_intern_hash.
    This places us on the gc list for the route cache garbage collector, so that
    when its refcount reaches zero, it will be reclaimed (Thanks to Alexey for this
    suggestion).
    
    I've tested this on a local system here, and with these patches in place, I'm
    able to maintain routed connectivity to remote systems, even if I set
    /proc/sys/net/ipv4/rt_cache_rebuild_count to -1, which forces rt_caching to
    return false.
    
    Signed-off-by: default avatarNeil Horman <nhorman@redhat.com>
    Reported-by: default avatarJarek Poplawski <jarkao2@gmail.com>
    Reported-by: default avatarMaxime Bizon <mbizon@freebox.fr>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    b6280b47