Re: [RFC PATCH] possible bug in handling of ipv4 route caching

[Chris Friesen <chris.friesen@windriver.com>]

On 04/07/2016 03:20 PM, Julian Anastasov wrote:
> On Thu, 7 Apr 2016, Chris Friesen wrote:
>
>> Hi,
>>
>> We think we may have found a bug in the handling of ipv4 route caching,
>> and are curious what you think.
>>
>> For local routes that require a particular output interface we do not
>> want to cache the result.  Caching the result causes incorrect behaviour
>> when there are multiple source addresses on the interface.  The end
>> result being that if the intended recipient is waiting on that interface
>> for the packet he won't receive it because it will be delivered on the
>> loopback interface and the IP_PKTINFO ipi_ifindex will be set to the
>> loopback interface as well.

>> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
>> index 02c6229..e965d4b 100644
>> --- a/net/ipv4/route.c
>> +++ b/net/ipv4/route.c
>> @@ -2045,6 +2045,17 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
>>   		 */
>>   		if (fi && res->prefixlen < 4)
>>   			fi = NULL;
>> +	} else if ((type == RTN_LOCAL) && (orig_oif != 0)) {
>
> 	So, we can be more specific. Can this work?:
>
> 	} else if ((type == RTN_LOCAL) && (orig_oif != 0) &&
> 		   (orig_oif != dev_out->ifindex)) {
>
> 	I.e. we should allow to cache orig_oif=LOOPBACK_IFINDEX
> but eth1 should not be cached.

Yes, we think that will work.  New patch to follow.

Chris