netdev - Re: [PATCH net-next 10/10] ipv6: Refactor __ip6_route

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<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.