Commit 1f9993f6 authored by Ying Xue's avatar Ying Xue Committed by David S. Miller

rocker: fix a neigh entry leak issue

Once we get a neighbour through looking up arp cache or creating a
new one in rocker_port_ipv4_resolve(), the neighbour's refcount is
already taken. But as we don't put the refcount again after it's
used, this makes the neighbour entry leaked.
Suggested-by: default avatarEric Dumazet <edumazet@google.com>
Acked-by: default avatarJiri Pirko <jiri@resnulli.us>
Acked-by: default avatarEric Dumazet <edumazet@google.com>
Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
Acked-by: default avatarJiri Pirko <jiri@resnulli.us>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent 86b5e7de
......@@ -2921,10 +2921,11 @@ static int rocker_port_ipv4_resolve(struct rocker_port *rocker_port,
struct neighbour *n = __ipv4_neigh_lookup(dev, (__force u32)ip_addr);
int err = 0;
if (!n)
if (!n) {
n = neigh_create(&arp_tbl, &ip_addr, dev);
if (!n)
return -ENOMEM;
if (IS_ERR(n))
return IS_ERR(n);
}
/* If the neigh is already resolved, then go ahead and
* install the entry, otherwise start the ARP process to
......@@ -2936,6 +2937,7 @@ static int rocker_port_ipv4_resolve(struct rocker_port *rocker_port,
else
neigh_event_send(n, NULL);
neigh_release(n);
return err;
}
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment