Merge branch 'neigh_cleanups'
authorDavid S. Miller <davem@davemloft.net>
Mon, 2 Mar 2015 21:43:46 +0000 (16:43 -0500)
committerDavid S. Miller <davem@davemloft.net>
Mon, 2 Mar 2015 21:43:46 +0000 (16:43 -0500)
commitb898441f4ece44933af90b116b467f7864dd1ae7
tree56316bfd883fa759f7a6fc7744088028b64e7b85
parent61e021f3b86cbbcc04cbe8ac7b7da2b8c94b5e8e
parent435e8eb27edb4da0b47b9b980239bd59057a7362
Merge branch 'neigh_cleanups'

Eric W. Biederman says:

====================
Neighbour table and ax25 cleanups

While looking at the neighbour table to what it would take to allow
using next hops in a different address family than the current packets
I found a partial resolution for my issues and I stumbled upon some
work that makes the neighbour table code easier to understand and
maintain.

Long ago in a much younger kernel ax25 found a hack to use
dev_rebuild_header to transmit it's packets instead of going through
what today is ndo_start_xmit.

When the neighbour table was rewritten into it's current form the ax25
code was such a challenge that arp_broken_ops appeard in arp.c and
neigh_compat_output appeared in neighbour.c to keep the ax25 hack alive.

With a little bit of work I was able to remove some of the hack that
is the ax25 transmit path for ip packets and to isolate what remains
into a slightly more readable piece of code in ax25_ip.c.  Removing the
need for the generic code to worry about ax25 special cases.

After cleaning up the old ax25 hacks I also performed a little bit of
work on neigh_resolve_output to remove the need for a dst entry and to
ensure cached headers get a deterministic protocol value in their cached
header.   This guarantees that a cached header will not be different
depending on which protocol of packet is transmitted, and it allows
packets to be transmitted that don't have a dst entry.  There remains
a small amount of code that takes advantage of when packets have a dst
entry but that is something different.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>