[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <edbcd283-845e-3b14-3541-57953d1a77a4@gmail.com>
Date: Wed, 10 Apr 2019 11:45:04 -0700
From: David Ahern <dsahern@...il.com>
To: Martin Lau <kafai@...com>, David Ahern <dsahern@...nel.org>
Cc: "davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"idosch@...lanox.com" <idosch@...lanox.com>
Subject: Re: [PATCH net-next 10/10] ipv6: Refactor __ip6_route_redirect
On 4/10/19 10:36 AM, Martin Lau wrote:
>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>> index 0e8becb1e455..d555edaaff13 100644
>> --- a/net/ipv6/route.c
>> +++ b/net/ipv6/route.c
>> @@ -2407,6 +2407,35 @@ void ip6_sk_dst_store_flow(struct sock *sk, struct dst_entry *dst,
>> NULL);
>> }
>>
>> +static bool ip6_redirect_nh_match(struct fib6_info *f6i,
>> + struct fib6_nh *nh,
> Why both "struct fib6_info" and "struct fib6_nh" are needed?
Because of rt6_find_cached_rt. At the moment it needs 2 entries from the
fib6_info. Patches in follow on sets affect rt6_find_cached_rt in 2 ways:
1. Exceptions and cached routes are moved to per-fib6_nh similar to what
is done for IPv4 in which case the need for fib6_info reduces to just
the fib6_src.plen
2. fib6_result is introduced and passed to rt6_find_cached_rt instead of
fib6_info and fib6_nh. It satisfies the need for fib6_src.plen from the
fib entry and the fib6_nh for everything else.
Something has to come first and in my experience with this overall
change, I feel this order has the least duplicity in changes.
> I assume nh cannot be obtained from f6i in the later patch
> when nh is decoupled from f6i?
correct
>
>> + struct flowi6 *fl6,
>> + const struct in6_addr *gw,
>> + struct rt6_info **ret)
>> +{
>> + if (nh->fib_nh_flags & RTNH_F_DEAD || !nh->fib_nh_gw_family ||
>> + fl6->flowi6_oif != nh->fib_nh_dev->ifindex)
>> + return false;
>> +
>> + /* rt_cache's gateway might be different from its 'parent'
>> + * in the case of an ip redirect.
>> + * So we keep searching in the exception table if the gateway
>> + * is different.
>> + */
>> + if (!ipv6_addr_equal(gw, &nh->fib_nh_gw6)) {
>> + struct rt6_info *rt_cache;
>> +
>> + rt_cache = rt6_find_cached_rt(f6i, &fl6->daddr, &fl6->saddr);
>> + if (rt_cache &&
>> + ipv6_addr_equal(gw, &rt_cache->rt6i_gateway)) {
>> + *ret = rt_cache;
>> + return true;
>> + }
>> + return false;
>> + }
>> + return true;
>> +}
>> +
>> /* Handle redirects */
>> struct ip6rd_flowi {
>> struct flowi6 fl6;
>> @@ -2420,7 +2449,7 @@ static struct rt6_info *__ip6_route_redirect(struct net *net,
>> int flags)
>> {
>> struct ip6rd_flowi *rdfl = (struct ip6rd_flowi *)fl6;
>> - struct rt6_info *ret = NULL, *rt_cache;
>> + struct rt6_info *ret = NULL;
>> struct fib6_info *rt;
> The "rt" naming is becoming hard to review.
> It is fortunate that the type context is kept in this diff.
>
> In this local case, the s/rt/f6i/ rename is quite doable?
I looked into it and I feel such a mass rename just causes noise:
$ egrep -r 'fib6_info \*rt[,;]' net | wc -l
50
so that's 50 functions that need to be updated and then all rt
references within the functions. A lot of noise which is why I have not
sent a name change patch.
> It can be the first clean-up step.
>
>> struct fib6_node *fn;
>>
>> @@ -2438,34 +2467,15 @@ static struct rt6_info *__ip6_route_redirect(struct net *net,
>> fn = fib6_node_lookup(&table->tb6_root, &fl6->daddr, &fl6->saddr);
>> restart:
>> for_each_fib6_node_rt_rcu(fn) {
>> - if (rt->fib6_nh.fib_nh_flags & RTNH_F_DEAD)
>> - continue;
>> if (fib6_check_expired(rt))
>> continue;
>> if (rt->fib6_flags & RTF_REJECT)
>> break;
>> - if (!rt->fib6_nh.fib_nh_gw_family)
>> - continue;
>> if (fl6->flowi6_oif != rt->fib6_nh.fib_nh_dev->ifindex)
> This check is also copied to the new ip6_redirect_nh_match.
> Should this one be removed from here?
good catch. It should be removed.
Powered by blists - more mailing lists