From: Paolo Abeni <pabeni@redhat.com>
To: Thomas Zeitlhofer <thomas.zeitlhofer+lkml@ze-it.at>,
"David S. Miller" <davem@davemloft.net>,
Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com>,
"Denis V. Lunev" <den@openvz.org>
Cc: Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
David Ahern <dsahern@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Yang Yingliang <yangyingliang@huawei.com>,
Muchun Song <songmuchun@bytedance.com>,
Vasily Averin <vasily.averin@linux.dev>,
Yuwei Wang <wangyuweihx@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: neigh: decrement the family specific qlen
Date: Tue, 15 Nov 2022 10:56:45 +0100 [thread overview]
Message-ID: <205d812ab74d721f4345eabcf3e5a86a710b40da.camel@redhat.com> (raw)
In-Reply-To: <Y295+9+JDjqRWbwU@x1.ze-it.at>
Hello,
On Sat, 2022-11-12 at 11:48 +0100, Thomas Zeitlhofer wrote:
> Commit 0ff4eb3d5ebb ("neighbour: make proxy_queue.qlen limit
> per-device") introduced the length counter qlen in struct neigh_parms.
> There are separate neigh_parms instances for IPv4/ARP and IPv6/ND, and
> while the family specific qlen is incremented in pneigh_enqueue(), the
> mentioned commit decrements always the IPv4/ARP specific qlen,
> regardless of the currently processed family, in pneigh_queue_purge()
> and neigh_proxy_process().
>
> As a result, with IPv6/ND, the family specific qlen is only incremented
> (and never decremented) until it exceeds PROXY_QLEN, and then, according
> to the check in pneigh_enqueue(), neighbor solicitations are not
> answered anymore. As an example, this is noted when using the
> subnet-router anycast address to access a Linux router. After a certain
> amount of time (in the observed case, qlen exceeded PROXY_QLEN after two
> days), the Linux router stops answering neighbor solicitations for its
> subnet-router anycast address and effectively becomes unreachable.
>
> Another result with IPv6/ND is that the IPv4/ARP specific qlen is
> decremented more often than incremented. This leads to negative qlen
> values, as a signed integer has been used for the length counter qlen,
> and potentially to an integer overflow.
>
> Fix this by introducing the helper function neigh_parms_qlen_dec(),
> which decrements the family specific qlen. Thereby, make use of the
> existing helper function neigh_get_dev_parms_rcu(), whose definition
> therefore needs to be placed earlier in neighbour.c. Take the family
> member from struct neigh_table to determine the currently processed
> family and appropriately call neigh_parms_qlen_dec() from
> pneigh_queue_purge() and neigh_proxy_process().
>
> Additionally, use an unsigned integer for the length counter qlen.
>
> Fixes: 0ff4eb3d5ebb ("neighbour: make proxy_queue.qlen limit per-device")
> Signed-off-by: Thomas Zeitlhofer <thomas.zeitlhofer+lkml@ze-it.at>
> ---
> include/net/neighbour.h | 2 +-
> net/core/neighbour.c | 58 +++++++++++++++++++++--------------------
> 2 files changed, 31 insertions(+), 29 deletions(-)
>
> diff --git a/include/net/neighbour.h b/include/net/neighbour.h
> index 20745cf7ae1a..cc0b65b7c829 100644
> --- a/include/net/neighbour.h
> +++ b/include/net/neighbour.h
> @@ -83,7 +83,7 @@ struct neigh_parms {
> struct rcu_head rcu_head;
>
> int reachable_time;
> - int qlen;
> + __u32 qlen;
> int data[NEIGH_VAR_DATA_MAX];
> DECLARE_BITMAP(data_state, NEIGH_VAR_DATA_MAX);
> };
The patch LGTM, but why did you use __u32 above? this is not part of
uAPI, plain u32 should be fine.
Thanks!
Paolo
next prev parent reply other threads:[~2022-11-15 9:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-12 10:48 Thomas Zeitlhofer
2022-11-15 9:56 ` Paolo Abeni [this message]
2022-11-15 22:09 ` [PATCH v2] " Thomas Zeitlhofer
2022-11-18 10:40 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=205d812ab74d721f4345eabcf3e5a86a710b40da.camel@redhat.com \
--to=pabeni@redhat.com \
--cc=alexander.mikhalitsyn@virtuozzo.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=den@openvz.org \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=songmuchun@bytedance.com \
--cc=thomas.zeitlhofer+lkml@ze-it.at \
--cc=vasily.averin@linux.dev \
--cc=wangyuweihx@gmail.com \
--cc=yangyingliang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®