include/net/ip6_fib.h | 3 ++- include/net/ip6_route.h | 5 +++-- net/ipv6/route.c | 11 ++--------- 3 files changed, 7 insertions(+), 12 deletions(-)
At some point after b5d2d75e079a ("net/ipv6: Do not allow device only
routes via the multipath API"), the IPv6 stack was updated such that
device-only multipath routes can be installed and work correctly.
This change removes checks that prevent them from being installed,
and adds a fib6_explicit_ecmp flag to fib6_info. The flag is only
checked in rt6_qualify_for_ecmp() and exists to prevent regressions.
Signed-off-by: azey <me@azey.net>
---
Changes in v2:
- Added fib6_explicit_ecmp flag to fib6_info to prevent regressions.
Very simple (and naive) fix, all it does is flag routes created as
multipath and check for the flag in rt6_qualify_for_ecmp().
I'm not sure whether it should be an RTF_ flag in fib6_flags instead,
but there aren't any unused bits in that field so I made it separate.
- Removed hanging has_gateway as reported by <lkp@intel.com> bot
Link to v1:
https://lore.kernel.org/netdev/a6vmtv3ylu224fnj5awi6xrgnjoib5r2jm3kny672hemsk5ifi@ychcxqnmy5us/
---
include/net/ip6_fib.h | 3 ++-
include/net/ip6_route.h | 5 +++--
net/ipv6/route.c | 11 ++---------
3 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 88b0dd4d8e09..da9d03cbbab4 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -196,7 +196,8 @@ struct fib6_info {
dst_nocount:1,
dst_nopolicy:1,
fib6_destroying:1,
- unused:4;
+ fib6_explicit_ecmp:1,
+ unused:3;
struct list_head purge_link;
struct rcu_head rcu;
diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index 7c5512baa4b2..5f00e9e252c2 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -73,8 +73,9 @@ static inline bool rt6_need_strict(const struct in6_addr *daddr)
static inline bool rt6_qualify_for_ecmp(const struct fib6_info *f6i)
{
/* the RTF_ADDRCONF flag filters out RA's */
- return !(f6i->fib6_flags & RTF_ADDRCONF) && !f6i->nh &&
- f6i->fib6_nh->fib_nh_gw_family;
+ return f6i->fib6_explicit_ecmp ||
+ (!(f6i->fib6_flags & RTF_ADDRCONF) && !f6i->nh &&
+ f6i->fib6_nh->fib_nh_gw_family);
}
void ip6_route_input(struct sk_buff *skb);
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index aee6a10b112a..7ac69bf5ccf2 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -5119,7 +5119,6 @@ static int rtm_to_fib6_multipath_config(struct fib6_config *cfg,
}
do {
- bool has_gateway = cfg->fc_flags & RTF_GATEWAY;
int attrlen = rtnh_attrlen(rtnh);
if (attrlen > 0) {
@@ -5133,17 +5132,9 @@ static int rtm_to_fib6_multipath_config(struct fib6_config *cfg,
"Invalid IPv6 address in RTA_GATEWAY");
return -EINVAL;
}
-
- has_gateway = true;
}
}
- if (newroute && (cfg->fc_nh_id || !has_gateway)) {
- NL_SET_ERR_MSG(extack,
- "Device only routes can not be added for IPv6 using the multipath API.");
- return -EINVAL;
- }
-
rtnh = rtnh_next(rtnh, &remaining);
} while (rtnh_ok(rtnh, remaining));
@@ -5448,6 +5439,8 @@ static int ip6_route_multipath_add(struct fib6_config *cfg,
goto cleanup;
}
+ rt->fib6_explicit_ecmp = true;
+
err = ip6_route_info_create_nh(rt, &r_cfg, GFP_KERNEL, extack);
if (err) {
rt = NULL;
base-commit: bd10acae08aeb9cd2f555acdbacb98b9fbb02a27
--
2.51.0
On Mon, 24 Nov 2025 14:52:45 +0100 azey wrote: > Signed-off-by: azey <me@azey.net> We need real/legal names because licenses are a legal matter. -- pw-bot: cr
On 2025-11-25 04:00:44 +0100 Jakub Kicinski <kuba@kernel.org> wrote: > On Mon, 24 Nov 2025 14:52:45 +0100 azey wrote: > > Signed-off-by: azey <me@azey.net> > > We need real/legal names because licenses are a legal matter. Apart from this, are there any other issues with the patch? I'd have no problems changing the sign-off if only just to get this applied faster (as I said, I mostly prefer the alias since my real name is not at all useful for contacting me, not that I "want to be anonymous online" as you put it). I still think the DCO docs agree with me, but my voice obviously isn't worth much and I agree there's really no need to involve Linus/Greg.
Le 26/11/2025 à 18:51, azey a écrit : > On 2025-11-25 04:00:44 +0100 Jakub Kicinski <kuba@kernel.org> wrote: >> On Mon, 24 Nov 2025 14:52:45 +0100 azey wrote: >>> Signed-off-by: azey <me@azey.net> >> >> We need real/legal names because licenses are a legal matter. > > Apart from this, are there any other issues with the patch? I still think that there could be regressions because this commit changes the default behavior. As stated for v1, having device-only multipath routes is already possible via the nexthop API.
On 2025-11-27 08:58:59 +0100 Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> I still think that there could be regressions because this commit changes the
> default behavior.
I don't think it should - my reasoning is that any routes created via
ip6_route_multipath_add() would always pass rt6_qualify_for_ecmp()
before this patch anyway:
- RAs get added as single routes via ip6_route_add(), so RTF_ADDRCONF
wouldn't be set
- f6i->nh wouldn't be set, since:
- ip6_route_info_create_nh() only sets nh if cfg->fc_nh_id is set,
otherwise sets fib6_nh
- rtm_to_fib6_config() prevents RTA_NH_ID and RTA_MULTIPATH from being
set at the same time, and only sets fc_nh_id if RTA_NH_ID is set
- f6i->fib6_nh->fib_nh_gw_family would always be set, as dev-only routes
were stopped by the check in rtm_to_fib6_multipath_config()
Did I get anything wrong? I should've probably included this in the commit
message, sorry.
> As stated for v1, having device-only multipath routes is already possible via
> the nexthop API.
I understand, however I still think it would be worth it to add this
to reconcile the v6/v4 APIs a bit better. If my reasoning is correct
and this doesn't cause regressions, it's a pretty trivial patch, and
FWIW as a user the feature would be very useful to me.
Le 27/11/2025 à 15:06, azey a écrit :
> On 2025-11-27 08:58:59 +0100 Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
>> I still think that there could be regressions because this commit changes the
>> default behavior.
>
> I don't think it should - my reasoning is that any routes created via
> ip6_route_multipath_add() would always pass rt6_qualify_for_ecmp()
> before this patch anyway:
> - RAs get added as single routes via ip6_route_add(), so RTF_ADDRCONF
> wouldn't be set
> - f6i->nh wouldn't be set, since:
> - ip6_route_info_create_nh() only sets nh if cfg->fc_nh_id is set,
> otherwise sets fib6_nh
> - rtm_to_fib6_config() prevents RTA_NH_ID and RTA_MULTIPATH from being
> set at the same time, and only sets fc_nh_id if RTA_NH_ID is set
> - f6i->fib6_nh->fib_nh_gw_family would always be set, as dev-only routes
> were stopped by the check in rtm_to_fib6_multipath_config()
>
> Did I get anything wrong? I should've probably included this in the commit
> message, sorry.
With IPv6, unlike IPv4, the ECMP next hops can be added one by one. Your commit
doesn't allow this:
$ ip -6 route add 2002::/64 via fd00:125::2 dev ntfp2
$ ip -6 route append 2002::/64 dev ntfp3
$ ip -6 route
2002::/64 via fd00:125::2 dev ntfp2 metric 1024 pref medium
2002::/64 dev ntfp3 metric 1024 pref medium
...
$ ip -6 route append 2002::/64 via fd00:175::2 dev ntfp3
$ ip -6 route
2002::/64 metric 1024 pref medium
nexthop via fd00:125::2 dev ntfp2 weight 1
nexthop via fd00:175::2 dev ntfp3 weight 1
Note that the previous route via ntfp3 has been removed.
On 2025-11-28 09:38:07 +0100 Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote: > With IPv6, unlike IPv4, the ECMP next hops can be added one by one. Your commit > doesn't allow this: > > $ ip -6 route add 2002::/64 via fd00:125::2 dev ntfp2 > $ ip -6 route append 2002::/64 dev ntfp3 > $ ip -6 route > 2002::/64 via fd00:125::2 dev ntfp2 metric 1024 pref medium > 2002::/64 dev ntfp3 metric 1024 pref medium > ... > $ ip -6 route append 2002::/64 via fd00:175::2 dev ntfp3 > $ ip -6 route > 2002::/64 metric 1024 pref medium > nexthop via fd00:125::2 dev ntfp2 weight 1 > nexthop via fd00:175::2 dev ntfp3 weight 1 > > Note that the previous route via ntfp3 has been removed. I just tested your example in a VM with my patch, and everything works as you described. This is due to fib6_explicit_ecmp not overriding rt6_qualify_for_ecmp(), but rather supplementing it with || - the intention was for default behavior to be preserved for routes that aren't created via ip6_route_multipath_add(), and from this example it seems to work correctly in that regard. And for ip6_route_multipath_add() routes, as I stated earlier the behavior should not change either (except for the gateway check, which is the only thing this patch wants to change). wg0 has fd00::1/64, wg1 has fd00::2/64; Exact command history: $ ip -6 r add 2002::/64 via fd00::2 dev wg0 $ ip -6 r append 2002::/64 dev wg1 $ ip -6 r 2002::/64 via fd00::2 dev wg0 metric 1024 pref medium 2002::/64 dev wg1 metric 1024 pref medium ... $ ip -6 r append 2002::/64 via fd01::2 dev wg1 $ ip -6 r 2002::/64 metric 1024 pref medium nexthop via fd00::2 dev wg0 weight 1 nexthop via fd01::2 dev wg1 weight 1 ... To also test the patch's functionality: $ ip -6 r add 2003::/64 nexthop dev wg0 nexthop dev wg1 $ ip -6 r 2002::/64 metric 1024 pref medium nexthop via fd00::2 dev wg0 weight 1 nexthop via fd01::2 dev wg1 weight 1 2003::/64 metric 1024 pref medium nexthop dev wg0 weight 1 nexthop dev wg1 weight 1 ... And to make sure the v1 regression isn't present: $ ip a add fd03::1/64 dev wg0 $ ip a add fd03::2/64 dev wg1 $ ip -6 r 2002::/64 metric 1024 pref medium nexthop via fd00::2 dev wg0 weight 1 nexthop via fd01::2 dev wg1 weight 1 2003::/64 metric 1024 pref medium nexthop dev wg0 weight 1 nexthop dev wg1 weight 1 fd03::/64 dev wg0 proto kernel metric 256 pref medium fd03::/64 dev wg1 proto kernel metric 256 pref medium ...
Le 28/11/2025 à 13:38, azey a écrit : > On 2025-11-28 09:38:07 +0100 Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote: >> With IPv6, unlike IPv4, the ECMP next hops can be added one by one. Your commit >> doesn't allow this: >> >> $ ip -6 route add 2002::/64 via fd00:125::2 dev ntfp2 >> $ ip -6 route append 2002::/64 dev ntfp3 >> $ ip -6 route >> 2002::/64 via fd00:125::2 dev ntfp2 metric 1024 pref medium >> 2002::/64 dev ntfp3 metric 1024 pref medium >> ... >> $ ip -6 route append 2002::/64 via fd00:175::2 dev ntfp3 >> $ ip -6 route >> 2002::/64 metric 1024 pref medium >> nexthop via fd00:125::2 dev ntfp2 weight 1 >> nexthop via fd00:175::2 dev ntfp3 weight 1 >> >> Note that the previous route via ntfp3 has been removed. > > I just tested your example in a VM with my patch, and everything works > as you described. This is due to fib6_explicit_ecmp not overriding I tested your patch ;-) 'ip -6 route append 2002::/64 dev ntfp3' failed to add the next hop, a second route was created.
On 2025-11-28 16:28:57 +0100 Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote: > Le 28/11/2025 à 13:38, azey a écrit : > > On 2025-11-28 09:38:07 +0100 Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote: > >> With IPv6, unlike IPv4, the ECMP next hops can be added one by one. Your commit > >> doesn't allow this: > >> > >> $ ip -6 route add 2002::/64 via fd00:125::2 dev ntfp2 > >> $ ip -6 route append 2002::/64 dev ntfp3 > >> $ ip -6 route > >> 2002::/64 via fd00:125::2 dev ntfp2 metric 1024 pref medium > >> 2002::/64 dev ntfp3 metric 1024 pref medium > >> ... > >> $ ip -6 route append 2002::/64 via fd00:175::2 dev ntfp3 > >> $ ip -6 route > >> 2002::/64 metric 1024 pref medium > >> nexthop via fd00:125::2 dev ntfp2 weight 1 > >> nexthop via fd00:175::2 dev ntfp3 weight 1 > >> > >> Note that the previous route via ntfp3 has been removed. > > > > I just tested your example in a VM with my patch, and everything works > > as you described. This is due to fib6_explicit_ecmp not overriding > I tested your patch ;-) > > 'ip -6 route append 2002::/64 dev ntfp3' failed to add the next hop, a second > route was created. Right, sorry! Still though, I tested the same thing without my patch and observed the exact same behavior: $ ip -6 r add 2002::/64 via fd00::2 dev wg0 $ ip -6 r append 2002::/64 dev wg1 $ ip -6 r 2002::/64 via fd00::2 dev wg0 metric 1024 pref medium 2002::/64 dev wg1 metric 1024 pref medium ... $ ip -6 r append 2002::/64 via fd01::2 dev wg1 $ ip -6 r 2002::/64 metric 1024 pref medium nexthop via fd00::2 dev wg0 weight 1 nexthop via fd01::2 dev wg1 weight 1 ... The 2002::/64 dev wg1 route also gets removed. Could you test this on your side to confirm? I think this is actually the current behavior.
> On 2025-11-28 09:38:07 +0100 Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote: >> With IPv6, unlike IPv4, the ECMP next hops can be added one by one. Your commit >> doesn't allow this: Hold on, I think I understand what you actually meant by this, sorry. I got too focused on regressions from the discussion in v1, I'll make a v3 of the patch that allows dev-only routes to be added via append.
Le 28/11/2025 à 16:54, azey a écrit : >> On 2025-11-28 09:38:07 +0100 Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote: >>> With IPv6, unlike IPv4, the ECMP next hops can be added one by one. Your commit >>> doesn't allow this: > > Hold on, I think I understand what you actually meant by this, sorry. > I got too focused on regressions from the discussion in v1, I'll make > a v3 of the patch that allows dev-only routes to be added via append. Yes, that is what I pointed out. Please, add some self-tests to show that there is no regression. You probably have to test different combinations of NLM_F_* flags. See: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/ip/iproute.c#n2418
On 2025-11-28 17:28:41 +0100 Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> Le 28/11/2025 à 16:54, azey a écrit :
> >> On 2025-11-28 09:38:07 +0100 Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> >>> With IPv6, unlike IPv4, the ECMP next hops can be added one by one. Your commit
> >>> doesn't allow this:
> >
> > Hold on, I think I understand what you actually meant by this, sorry.
> > I got too focused on regressions from the discussion in v1, I'll make
> > a v3 of the patch that allows dev-only routes to be added via append.
> Yes, that is what I pointed out.
>
> Please, add some self-tests to show that there is no regression. You probably
> have to test different combinations of NLM_F_* flags. See:
>
> https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/ip/iproute.c#n2418
Will do, thanks for the pointer.
One last thing I'd like to clarify though: would this behavior not also
itself be considered a regression?
Currently the add and append routes get added separately, and someone
could theoretically be relying on the kernel always picking the last
route instead of making them multipath - essentially still the same
v1 regression.
If not, would it also be acceptable for just any non-RTPROT_KERNEL
routes to automatically be made multipath like this? It's a simple fix,
it'd make appending work and it'd still prevent the specific v1
regression for the case of two interfaces on the same subnet - example
diff attached.
---
include/net/ip6_route.h | 6 ++++--
net/ipv6/route.c | 9 ---------
2 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index 7c5512baa4b2..c20beb7bcdb9 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -72,9 +72,11 @@ static inline bool rt6_need_strict(const struct in6_addr *daddr)
*/
static inline bool rt6_qualify_for_ecmp(const struct fib6_info *f6i)
{
- /* the RTF_ADDRCONF flag filters out RA's */
+ /* the RTF_ADDRCONF flag filters out RA's,
+ * and RTPROT_KERNEL filters out local addresses' subnet routes
+ */
return !(f6i->fib6_flags & RTF_ADDRCONF) && !f6i->nh &&
- f6i->fib6_nh->fib_nh_gw_family;
+ (f6i->fib6_nh->fib_nh_gw_family || f6i->fib6_protocol != RTPROT_KERNEL);
}
void ip6_route_input(struct sk_buff *skb);
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index aee6a10b112a..865d9139994a 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -5119,7 +5119,6 @@ static int rtm_to_fib6_multipath_config(struct fib6_config *cfg,
}
do {
- bool has_gateway = cfg->fc_flags & RTF_GATEWAY;
int attrlen = rtnh_attrlen(rtnh);
if (attrlen > 0) {
@@ -5133,17 +5132,9 @@ static int rtm_to_fib6_multipath_config(struct fib6_config *cfg,
"Invalid IPv6 address in RTA_GATEWAY");
return -EINVAL;
}
-
- has_gateway = true;
}
}
- if (newroute && (cfg->fc_nh_id || !has_gateway)) {
- NL_SET_ERR_MSG(extack,
- "Device only routes can not be added for IPv6 using the multipath API.");
- return -EINVAL;
- }
-
rtnh = rtnh_next(rtnh, &remaining);
} while (rtnh_ok(rtnh, remaining));
base-commit: bd10acae08aeb9cd2f555acdbacb98b9fbb02a27
--
2.51.0
Le 28/11/2025 à 18:49, azey a écrit : > On 2025-11-28 17:28:41 +0100 Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote: >> Le 28/11/2025 à 16:54, azey a écrit : >>>> On 2025-11-28 09:38:07 +0100 Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote: >>>>> With IPv6, unlike IPv4, the ECMP next hops can be added one by one. Your commit >>>>> doesn't allow this: >>> >>> Hold on, I think I understand what you actually meant by this, sorry. >>> I got too focused on regressions from the discussion in v1, I'll make >>> a v3 of the patch that allows dev-only routes to be added via append. >> Yes, that is what I pointed out. >> >> Please, add some self-tests to show that there is no regression. You probably >> have to test different combinations of NLM_F_* flags. See: >> >> https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/ip/iproute.c#n2418 > > Will do, thanks for the pointer. > One last thing I'd like to clarify though: would this behavior not also > itself be considered a regression? > > Currently the add and append routes get added separately, and someone > could theoretically be relying on the kernel always picking the last > route instead of making them multipath - essentially still the same > v1 regression. That's a good question. I let others speak. But using the nexthop API would definitely close this question. I wonder why using this API is not possible for you. > > If not, would it also be acceptable for just any non-RTPROT_KERNEL > routes to automatically be made multipath like this? It's a simple fix, > it'd make appending work and it'd still prevent the specific v1 > regression for the case of two interfaces on the same subnet - example > diff attached. I don't think that the protocol field is reliable. The user can set it to whatever he wants.
On 2025-11-28 13:38:58 +0100 azey <me@azey.net> wrote: > wg0 has fd00::1/64, wg1 has fd00::2/64; Exact command history: Mistyped, my apologies. wg0 had fd00::1/64, wg1 had fd01::1/64.
On 2025-11-25 04:00:44 +0100 Jakub Kicinski <kuba@kernel.org> wrote:
> On Mon, 24 Nov 2025 14:52:45 +0100 azey wrote:
> > Signed-off-by: azey <me@azey.net>
>
> We need real/legal names because licenses are a legal matter.
> --
> pw-bot: cr
I was under the impression this was clarified in d4563201f33a
("Documentation: simplify and clarify DCO contribution example
language") to not be the case, are there different rules for this
subsystem? I think it qualifies as a "known identity" since I use
the alias basically everywhere (github, website, GPG, email, etc).
On Tue, 25 Nov 2025 04:15:25 +0100 azey wrote:
> On 2025-11-25 04:00:44 +0100 Jakub Kicinski <kuba@kernel.org> wrote:
> > On Mon, 24 Nov 2025 14:52:45 +0100 azey wrote:
> > > Signed-off-by: azey <me@azey.net>
> >
> > We need real/legal names because licenses are a legal matter.
> > --
> > pw-bot: cr
>
> I was under the impression this was clarified in d4563201f33a
> ("Documentation: simplify and clarify DCO contribution example
> language") to not be the case, are there different rules for this
> subsystem? I think it qualifies as a "known identity" since I use
> the alias basically everywhere (github, website, GPG, email, etc).
My understanding is that if I know you, I can apply your patch even
if you use your nick name (rather than what you have in your passport
letter for letter).
I don't know you.
If you're saying that I can do some research and find out who you are
please be aware that we deal with 700 individual per release just
in networking.
On 2025-11-25 04:25:50 +0100 Jakub Kicinski <kuba@kernel.org> wrote:
> On Tue, 25 Nov 2025 04:15:25 +0100 azey wrote:
> > On 2025-11-25 04:00:44 +0100 Jakub Kicinski <kuba@kernel.org> wrote:
> > > On Mon, 24 Nov 2025 14:52:45 +0100 azey wrote:
> > > > Signed-off-by: azey <me@azey.net>
> > >
> > > We need real/legal names because licenses are a legal matter.
> > > --
> > > pw-bot: cr
> >
> > I was under the impression this was clarified in d4563201f33a
> > ("Documentation: simplify and clarify DCO contribution example
> > language") to not be the case, are there different rules for this
> > subsystem? I think it qualifies as a "known identity" since I use
> > the alias basically everywhere (github, website, GPG, email, etc).
>
> My understanding is that if I know you, I can apply your patch even
> if you use your nick name (rather than what you have in your passport
> letter for letter).
>
> I don't know you.
>
> If you're saying that I can do some research and find out who you are
> please be aware that we deal with 700 individual per release just
> in networking.
My main concern is that I keep my on/offline identities very separated,
so you couldn't find me by my real name anywhere online. And offline,
my legal name is common enough that you couldn't single me out by it
alone either.
My understanding is that the sign-off name should be what you can
identify and contact me by in case of any problems, which my legal
name is not. As per Linus' commit I linked:
> the sign-off needed to be something we could check back with.
> we've always accepted nicknames
> the wording [..] shouldn't be causing unnecessary angst and pain,
> or scare away people who go by preferred naming.
If the concern is that it isn't unique enough, I could change it to
azey7f as that's a username I use when just azey isn't available,
though my commits are always authored "azey <me@azey.net>".
On Tue, 25 Nov 2025 05:00:59 +0100 azey wrote: > > My understanding is that if I know you, I can apply your patch even > > if you use your nick name (rather than what you have in your passport > > letter for letter). > > > > I don't know you. > > > > If you're saying that I can do some research and find out who you are > > please be aware that we deal with 700 individual per release just > > in networking. > > My main concern is that I keep my on/offline identities very separated, > so you couldn't find me by my real name anywhere online. And offline, > my legal name is common enough that you couldn't single me out by it > alone either. > > My understanding is that the sign-off name should be what you can > identify and contact me by in case of any problems, which my legal > name is not. As per Linus' commit I linked: > > > the sign-off needed to be something we could check back with. Feel free to appeal to Linus or Greg KH if you think it's worth their time (I don't). I hope I don't regret saying this. But my understanding is that the real reason the wording was changed was that there are surprisingly many countries in the world which have legal requirements on the name. For instance, in the past(!) Greece forced Macedonians to use a Greekified spelling of their name. IDK the details but IIUC Lithuania requires certain spelling of Polish names too (I could be wrong). etc. The rule was loosened because someone may culturally want to spell their name one way, but their "legal" name is forced to be localized. It does not mean we will entertain people who "want to be anonymous online". This is my final comment on this.
On 2025-11-25 05:20:37 +0100 Jakub Kicinski <kuba@kernel.org> wrote: > On Tue, 25 Nov 2025 05:00:59 +0100 azey wrote: > > My main concern is that I keep my on/offline identities very separated, > > so you couldn't find me by my real name anywhere online. And offline, > > my legal name is common enough that you couldn't single me out by it > > alone either. > > > > My understanding is that the sign-off name should be what you can > > identify and contact me by in case of any problems, which my legal > > name is not. As per Linus' commit I linked: > > > > > the sign-off needed to be something we could check back with. > > Feel free to appeal to Linus or Greg KH if you think it's worth their > time (I don't). > > I hope I don't regret saying this. But my understanding is that the > real reason the wording was changed was that there are surprisingly > many countries in the world which have legal requirements on the name. > For instance, in the past(!) Greece forced Macedonians to use a > Greekified spelling of their name. IDK the details but IIUC Lithuania > requires certain spelling of Polish names too (I could be wrong). etc. > > The rule was loosened because someone may culturally want to spell > their name one way, but their "legal" name is forced to be localized. Just looking through the commit history, there are plenty of one-off contributors using nicknames. E.g.: git log --pretty=format:"%an <%ae>" | grep '^[A-Za-z0-9]* <' | sort | uniq -u This shows ~700 authors with a single commit which identify themselves with a first name or alias only, so I don't think this can be true. Also, I feel like that'd be indicated in the commit message if it was. > It does not mean we will entertain people who "want to be anonymous > online". > > This is my final comment on this. Mine as well, until someone else chimes in.
© 2016 - 2025 Red Hat, Inc.