linux-kernel - Re: [PATCH net-next v2 1/1] net: neigh: persist proxy config across link flaps

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7211782676442c6679d8a016813fd62d44cbebad.camel@gmail.com>
Date:   Thu, 15 Dec 2022 08:24:15 -0800
From:   Alexander H Duyck <alexander.duyck@...il.com>
To:     David Decotigny <decot+git@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Cc:     Nikolay Aleksandrov <razor@...ckwall.org>,
        David Ahern <dsahern@...nel.org>,
        "Denis V. Lunev" <den@...nvz.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Chen Zhongjin <chenzhongjin@...wei.com>,
        David Decotigny <ddecotig@...gle.com>,
        Yuwei Wang <wangyuweihx@...il.com>,
        Alexander Mikhalitsyn <alexander.mikhalitsyn@...tuozzo.com>,
        Thomas Zeitlhofer <thomas.zeitlhofer+lkml@...it.at>
Subject: Re: [PATCH net-next v2 1/1] net: neigh: persist proxy config across
 link flaps

On Wed, 2022-12-14 at 15:20 -0800, David Decotigny wrote:
> From: David Decotigny <ddecotig@...gle.com>
> 
> Without this patch, the 'ip neigh add proxy' config is lost when the
> cable or peer disappear, ie. when the link goes down while staying
> admin up. When the link comes back, the config is never recovered.
> 
> This patch makes sure that such an nd proxy config survives a switch
> or cable issue.
> 
> Signed-off-by: David Decotigny <ddecotig@...gle.com>
> 
> 
> ---
> v1: initial revision
> v2: same as v1, except rebased on top of latest net-next, and includes "net-next" in the description
> 
>  net/core/neighbour.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index f00a79fc301b..f4b65bbbdc32 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -426,7 +426,10 @@ static int __neigh_ifdown(struct neigh_table *tbl, struct net_device *dev,
>  {
>  	write_lock_bh(&tbl->lock);
>  	neigh_flush_dev(tbl, dev, skip_perm);
> -	pneigh_ifdown_and_unlock(tbl, dev);
> +	if (skip_perm)
> +		write_unlock_bh(&tbl->lock);
> +	else
> +		pneigh_ifdown_and_unlock(tbl, dev);
>  	pneigh_queue_purge(&tbl->proxy_queue, dev ? dev_net(dev) : NULL,
>  			   tbl->family);
>  	if (skb_queue_empty_lockless(&tbl->proxy_queue))

This seems like an agressive approach since it applies to all entries
in the table, not just the permenant ones like occurs in
neigh_flush_dev.

I don't have much experience in this area of the code but it seems like
you would specifically be wanting to keep only the permanant entries.
Would it make sense ot look at rearranging pneigh_ifdown_and_unlock so
that the code functioned more like neigh_flush_dev where it only
skipped the permanant entries when skip_perm was set?