[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250416184845.293-1-kuniyu@amazon.com>
Date: Wed, 16 Apr 2025 11:48:43 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <pabeni@...hat.com>
CC: <davem@...emloft.net>, <dsahern@...nel.org>, <edumazet@...gle.com>,
<horms@...nel.org>, <kuba@...nel.org>, <kuni1840@...il.com>,
<kuniyu@...zon.com>, <netdev@...r.kernel.org>
Subject: Re: [PATCH RESEND v2 net-next 04/14] ipv6: Check GATEWAY in rtm_to_fib6_multipath_config().
From: Paolo Abeni <pabeni@...hat.com>
Date: Wed, 16 Apr 2025 11:06:30 +0200
> On 4/14/25 8:14 PM, Kuniyuki Iwashima wrote:
> > In ip6_route_multipath_add(), we call rt6_qualify_for_ecmp() for each
> > entry. If it returns false, the request fails.
> >
> > rt6_qualify_for_ecmp() returns false if either of the conditions below
> > is true:
> >
> > 1. f6i->fib6_flags has RTF_ADDRCONF
> > 2. f6i->nh is not NULL
> > 3. f6i->fib6_nh->fib_nh_gw_family is AF_UNSPEC
> >
> > 1 is unnecessary because rtm_to_fib6_config() never sets RTF_ADDRCONF
> > to cfg->fc_flags.
> >
> > 2. is equivalent with cfg->fc_nh_id.
> >
> > 3. can be replaced by checking RTF_GATEWAY in the base and each multipath
> > entry because AF_INET6 is set to f6i->fib6_nh->fib_nh_gw_family only when
> > cfg.fc_is_fdb is true or RTF_GATEWAY is set, but the former is always
> > false.
> >
> > Let's perform the equivalent checks in rtm_to_fib6_multipath_config().
>
> It's unclear to me the 'why'???
It's just because this validation does not need to be done under RCU.
Or are you asking why I didn't use rt6_qualify_for_ecmp() ?
Powered by blists - more mailing lists