From: Julian Anastasov <ja@ssi.bg>
To: Zhang Changzhong <zhangchangzhong@huawei.com>
Cc: Network Development <netdev@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
David Ahern <dsahern@kernel.org>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
"Denis V. Lunev" <den@openvz.org>,
Nikolay Aleksandrov <razor@blackwall.org>,
Daniel Borkmann <daniel@iogearbox.net>,
YueHaibing <yuehaibing@huawei.com>
Subject: Re: [Question] neighbor entry doesn't switch to the STALE state after the reachable timer expires
Date: Tue, 31 Jan 2023 18:13:50 +0200 (EET) [thread overview]
Message-ID: <d95e4afc-3a95-a3a7-edd9-1bd13cdec90@ssi.bg> (raw)
In-Reply-To: <1252089d-75db-a45c-d735-6883c772d95a@huawei.com>
Hello,
On Tue, 31 Jan 2023, Zhang Changzhong wrote:
> Thanks for your fix!
>
> I reproduced this problem by directly modifying the confirmed time of
> the neigh entry in STALE state. Your change can fix the problem in this
> scenario.
I'm glad that you have a way to test it :) Thanks!
> Just curious, why did you choose 'jiffies - MAX_JIFFY_OFFSET + 86400 * HZ'
> as the value of 'mint'?
It is too arbitrary :) Probably, just 'jiffies - MAX_JIFFY_OFFSET'
is enough or something depending on HZ/USER_HZ. I added 1 day for
timer to advance without leaving confirmed time behind the
jiffies - MAX_JIFFY_OFFSET zone but it is not needed.
What limits play here:
- the HZ/USER_HZ difference: jiffies_to_clock_t reports the 3 times
to user space, so we want to display values as large as possible.
Any HZ > 100 for USER_HZ=100 works for the jiffies - MAX_JIFFY_OFFSET.
HZ=100 does not work.
- users can use large values for sysctl vars which can keep the timer
running for long time and reach some outdated confirmed time
before neigh_add_timer() is called to correct it
If we choose mint = jiffies - MAX_JIFFY_OFFSET,
for 32-bit we will have:
Past Future
++++++++++++++++++++++++++++++++++++++++++++++++++++
| 49 days | 49 days | 99 days |
++++++++++++++^+++++++++++^+++++++++++++++++++++++++
^ ^
DELAY+PROBE | |
mint now
- used/confirmed times should be up to 49 days behind jiffies but
we have 49 days to stay in timer without correcting them,
so they can go up to 99 days in the past before going in
the future and trigger the problem
- as we avoid the checks in neigh_timer_handler to save CPU cycles,
one needs crazy sysctl settings to keep the timer in DELAY+PROBE
states for 49 days. With default settings, it is no more than
half minute. In this case even
mint = jiffies - LONG_MAX + 86400 * HZ should work.
- REACHABLE state extends while confirmed time advances,
otherwise PROBE will need ARP reply to recheck the
times in neigh_add_timer while entering REACHABLE again
Regards
--
Julian Anastasov <ja@ssi.bg>
next prev parent reply other threads:[~2023-01-31 16:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-29 3:08 Zhang Changzhong
2023-01-29 19:43 ` Julian Anastasov
2023-01-30 3:19 ` Zhang Changzhong
2023-01-30 11:01 ` Julian Anastasov
2023-01-31 11:52 ` Zhang Changzhong
2023-01-31 16:13 ` Julian Anastasov [this message]
2023-02-02 8:27 ` Zhang Changzhong
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=d95e4afc-3a95-a3a7-edd9-1bd13cdec90@ssi.bg \
--to=ja@ssi.bg \
--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=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=yoshfuji@linux-ipv6.org \
--cc=yuehaibing@huawei.com \
--cc=zhangchangzhong@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®