• David Ahern's avatar
    ipv4: Add helpers for neigh lookup for nexthop · 5c9f7c1d
    David Ahern authored
    A common theme in the output path is looking up a neigh entry for a
    nexthop, either the gateway in an rtable or a fallback to the daddr
    in the skb:
    
            nexthop = (__force u32)rt_nexthop(rt, ip_hdr(skb)->daddr);
            neigh = __ipv4_neigh_lookup_noref(dev, nexthop);
            if (unlikely(!neigh))
                    neigh = __neigh_create(&arp_tbl, &nexthop, dev, false);
    
    To allow the nexthop to be an IPv6 address we need to consider the
    family of the nexthop and then call __ipv{4,6}_neigh_lookup_noref based
    on it.
    
    To make this simpler, add a ip_neigh_gw4 helper similar to ip_neigh_gw6
    added in an earlier patch which handles:
    
            neigh = __ipv4_neigh_lookup_noref(dev, nexthop);
            if (unlikely(!neigh))
                    neigh = __neigh_create(&arp_tbl, &nexthop, dev, false);
    
    And then add a second one, ip_neigh_for_gw, that calls either
    ip_neigh_gw4 or ip_neigh_gw6 based on the address family of the gateway.
    
    Update the output paths in the VRF driver and core v4 code to use
    ip_neigh_for_gw simplifying the family based lookup and making both
    ready for a v6 nexthop.
    
    ipv4_neigh_lookup has a different need - the potential to resolve a
    passed in address in addition to any gateway in the rtable or skb. Since
    this is a one-off, add ip_neigh_gw4 and ip_neigh_gw6 diectly. The
    difference between __neigh_create used by the helpers and neigh_create
    called by ipv4_neigh_lookup is taking a refcount, so add rcu_read_lock_bh
    and bump the refcnt on the neigh entry.
    Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    5c9f7c1d
ip_output.c 40 KB