[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9771903e-3e7b-4391-dac8-bf7d0785e4c9@gmail.com>
Date: Tue, 12 Oct 2021 08:23:28 -0600
From: David Ahern <dsahern@...il.com>
To: Daniel Borkmann <daniel@...earbox.net>, davem@...emloft.net,
kuba@...nel.org
Cc: roopa@...dia.com, dsahern@...nel.org, m@...bda.lt,
john.fastabend@...il.com, netdev@...r.kernel.org,
bpf@...r.kernel.org
Subject: Re: [PATCH net-next 1/4] net, neigh: Fix NTF_EXT_LEARNED in
combination with NTF_USE
On 10/11/21 6:12 AM, Daniel Borkmann wrote:
> The NTF_EXT_LEARNED neigh flag is usually propagated back to user space
> upon dump of the neighbor table. However, when used in combination with
> NTF_USE flag this is not the case despite exempting the entry from the
> garbage collector. This results in inconsistent state since entries are
> typically marked in neigh->flags with NTF_EXT_LEARNED, but here they are
> not. Fix it by propagating the creation flag to ___neigh_create().
>
> Before fix:
>
> # ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn
> # ./ip/ip n
> 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a REACHABLE
> [...]
>
> After fix:
>
> # ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn
> # ./ip/ip n
> 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a extern_learn REACHABLE
> [...]
>
> Fixes: 9ce33e46531d ("neighbour: support for NTF_EXT_LEARNED flag")
> Signed-off-by: Daniel Borkmann <daniel@...earbox.net>
> Acked-by: Roopa Prabhu <roopa@...dia.com>
> ---
> net/core/neighbour.c | 26 ++++++++++++++------------
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
Reviewed-by: David Ahern <dsahern@...nel.org>
Powered by blists - more mailing lists