Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <7211782676442c6679d8a016813fd62d44cbebad.camel@gmail.com>
Subject: Re: [PATCH net-next v2 1/1] net: neigh: persist proxy config across
 link flaps
From:   Alexander H Duyck <alexander.duyck@gmail.com>
To:     David Decotigny <decot+git@google.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Cc:     Nikolay Aleksandrov <razor@blackwall.org>,
        David Ahern <dsahern@kernel.org>,
        "Denis V. Lunev" <den@openvz.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Chen Zhongjin <chenzhongjin@huawei.com>,
        David Decotigny <ddecotig@google.com>,
        Yuwei Wang <wangyuweihx@gmail.com>,
        Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com>,
        Thomas Zeitlhofer <thomas.zeitlhofer+lkml@ze-it.at>
Date:   Thu, 15 Dec 2022 08:24:15 -0800
In-Reply-To: <20221214232059.760233-1-decot+git@google.com>
References: <20221214232059.760233-1-decot+git@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) 
MIME-Version: 1.0
Precedence: bulk

On Wed, 2022-12-14 at 15:20 -0800, David Decotigny wrote:
> From: David Decotigny <ddecotig@google.com>
>=20
> 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.
>=20
> This patch makes sure that such an nd proxy config survives a switch
> or cable issue.
>=20
> Signed-off-by: David Decotigny <ddecotig@google.com>
>=20
>=20
> ---
> v1: initial revision
> v2: same as v1, except rebased on top of latest net-next, and includes "n=
et-next" in the description
>=20
>  net/core/neighbour.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>=20
> 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, s=
truct 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?