From: Paolo Abeni <pabeni@redhat.com>
To: Alex Henrie <alexhenrie24@gmail.com>,
netdev@vger.kernel.org, jbohac@suse.cz,
benoit.boissinot@ens-lyon.org, davem@davemloft.net,
hideaki.yoshifuji@miraclelinux.com, dsahern@kernel.org
Subject: Re: [PATCH v2 2/5] net: ipv6/addrconf: clamp preferred_lft to the maximum allowed
Date: Thu, 31 Aug 2023 10:25:47 +0200 [thread overview]
Message-ID: <60d9d5f57fdb55a27748996d807712c680c4e7f9.camel@redhat.com> (raw)
In-Reply-To: <20230829054623.104293-3-alexhenrie24@gmail.com>
On Mon, 2023-08-28 at 23:44 -0600, Alex Henrie wrote:
> Without this patch, there is nothing to stop the preferred lifetime of a
> temporary address from being greater than its valid lifetime. If that
> was the case, the valid lifetime was effectively ignored.
AFAICS this change makes the ipv6 implementation more in compliance
with the RFC, but on the flip side it will also break existing users
(if any) which set preferred > valid as a way to get an unlimited
validity period.
I'm quite unsure if the above is really the best option, but I think it
should not threaded as a fix.
My suggestion would be to re-send the uncontroversial patch 1/5 as a
stand-alone fix, and the following patches as a series targeting net-
next (no fixes tag there).
Cheers,
Paolo
next prev parent reply other threads:[~2023-08-31 8:25 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-21 1:11 [PATCH] ipv6/addrconf: clamp preferred_lft to the minimum instead of erroring Alex Henrie
2023-08-22 9:54 ` Paolo Abeni
2023-08-23 3:41 ` Alex Henrie
2023-08-23 3:45 ` David Ahern
2023-08-23 8:36 ` Jiri Bohac
2023-08-23 11:00 ` Paolo Abeni
2023-08-29 5:44 ` [PATCH v2 0/5] net: ipv6/addrconf: ensure that temporary addresses' preferred lifetimes are in the valid range Alex Henrie
2023-08-29 5:44 ` [PATCH v2 1/5] net: ipv6/addrconf: avoid integer underflow in ipv6_create_tempaddr Alex Henrie
2023-09-01 4:41 ` [PATCH v3] " Alex Henrie
2023-09-01 13:53 ` David Ahern
2023-09-04 6:21 ` patchwork-bot+netdevbpf
2023-08-29 5:44 ` [PATCH v2 2/5] net: ipv6/addrconf: clamp preferred_lft to the maximum allowed Alex Henrie
2023-08-31 8:25 ` Paolo Abeni [this message]
2023-08-29 5:44 ` [PATCH v2 3/5] net: ipv6/addrconf: clamp preferred_lft to the minimum required Alex Henrie
2023-08-31 1:28 ` Jakub Kicinski
2023-08-31 5:40 ` Alex Henrie
2023-08-29 5:44 ` [PATCH v2 4/5] Documentation: networking: explain what happens if temp_valid_lft is too small Alex Henrie
2023-08-29 5:44 ` [PATCH v2 5/5] Documentation: networking: explain what happens if temp_prefered_lft is too small or too large Alex Henrie
2023-08-31 8:33 ` Paolo Abeni
2023-10-24 19:40 ` [PATCH resend 1/4] net: ipv6/addrconf: clamp preferred_lft to the maximum allowed Alex Henrie
2023-10-24 19:40 ` [PATCH resend 2/4] net: ipv6/addrconf: clamp preferred_lft to the minimum required Alex Henrie
2023-10-24 19:40 ` [PATCH resend 3/4] Documentation: networking: explain what happens if temp_valid_lft is too small Alex Henrie
2023-10-24 19:40 ` [PATCH resend 4/4] Documentation: networking: explain what happens if temp_prefered_lft is too small or too large Alex Henrie
2023-10-24 19:48 ` [PATCH resend 1/4] net: ipv6/addrconf: clamp preferred_lft to the maximum allowed Jakub Kicinski
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=60d9d5f57fdb55a27748996d807712c680c4e7f9.camel@redhat.com \
--to=pabeni@redhat.com \
--cc=alexhenrie24@gmail.com \
--cc=benoit.boissinot@ens-lyon.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=hideaki.yoshifuji@miraclelinux.com \
--cc=jbohac@suse.cz \
--cc=netdev@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).