summaryrefslogtreecommitdiffstats
path: root/net/core
diff options
context:
space:
mode:
authorDavid Ahern <dsahern@gmail.com>2019-05-01 18:08:34 -0700
committerDavid S. Miller <davem@davemloft.net>2019-05-04 00:36:19 -0400
commit64c6f4bbca748c3b2101469a76d88b7cd1c00476 (patch)
tree4bae5434e1190ed072ea51ccb2389843653f34bd /net/core
parentf0c5bcf2f43f122ec84161992dc9d9d994d53fdb (diff)
downloadlinux-64c6f4bbca748c3b2101469a76d88b7cd1c00476.tar.gz
linux-64c6f4bbca748c3b2101469a76d88b7cd1c00476.tar.bz2
linux-64c6f4bbca748c3b2101469a76d88b7cd1c00476.zip
neighbor: Reset gc_entries counter if new entry is released before insert
Ian and Alan both reported seeing overflows after upgrades to 5.x kernels: neighbour: arp_cache: neighbor table overflow! Alan's mpls script helped get to the bottom of this bug. When a new entry is created the gc_entries counter is bumped in neigh_alloc to check if a new one is allowed to be created. ___neigh_create then searches for an existing entry before inserting the just allocated one. If an entry already exists, the new one is dropped in favor of the existing one. In this case the cleanup path needs to drop the gc_entries counter. There is no memory leak, only a counter leak. Fixes: 58956317c8d ("neighbor: Improve garbage collection") Reported-by: Ian Kumlien <ian.kumlien@gmail.com> Reported-by: Alan Maguire <alan.maguire@oracle.com> Signed-off-by: David Ahern <dsahern@gmail.com> Tested-by: Alan Maguire <alan.maguire@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/core')
-rw-r--r--net/core/neighbour.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 30f6fd8f68e0..aff051e5521d 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -663,6 +663,8 @@ out:
out_tbl_unlock:
write_unlock_bh(&tbl->lock);
out_neigh_release:
+ if (!exempt_from_gc)
+ atomic_dec(&tbl->gc_entries);
neigh_release(n);
goto out;
}