summaryrefslogtreecommitdiffstats
path: root/kernel/trace
diff options
context:
space:
mode:
authorSowmini Varadhan <sowmini.varadhan@oracle.com>2017-06-02 09:01:49 -0700
committerDavid S. Miller <davem@davemloft.net>2017-06-04 21:37:18 -0400
commit5071034e4af709d6783b7d105dc296a5cc84739b (patch)
tree1817b75dea97eee82647e69c498c35c4d886ece3 /kernel/trace
parent030a89028db07a7987f1f3bd6ee43114e36f5060 (diff)
downloadop-kernel-dev-5071034e4af709d6783b7d105dc296a5cc84739b.zip
op-kernel-dev-5071034e4af709d6783b7d105dc296a5cc84739b.tar.gz
neigh: Really delete an arp/neigh entry on "ip neigh delete" or "arp -d"
The command # arp -s 62.2.0.1 a:b:c:d:e:f dev eth2 adds an entry like the following (listed by "arp -an") ? (62.2.0.1) at 0a:0b:0c:0d:0e:0f [ether] PERM on eth2 but the symmetric deletion command # arp -i eth2 -d 62.2.0.1 does not remove the PERM entry from the table, and instead leaves behind ? (62.2.0.1) at <incomplete> on eth2 The reason is that there is a refcnt of 1 for the arp_tbl itself (neigh_alloc starts off the entry with a refcnt of 1), thus the neigh_release() call from arp_invalidate() will (at best) just decrement the ref to 1, but will never actually free it from the table. To fix this, we need to do something like neigh_forced_gc: if the refcnt is 1 (i.e., on the table's ref), remove the entry from the table and free it. This patch refactors and shares common code between neigh_forced_gc and the newly added neigh_remove_one. A similar issue exists for IPv6 Neighbor Cache entries, and is fixed in a similar manner by this patch. Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Reviewed-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'kernel/trace')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud