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
| ||
|
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?
Powered by blists - more mailing lists