[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5707C7A3.2040904@windriver.com>
Date: Fri, 8 Apr 2016 09:00:51 -0600
From: Chris Friesen <chris.friesen@...driver.com>
To: Julian Anastasov <ja@....bg>
CC: netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH] possible bug in handling of ipv4 route caching
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
Powered by blists - more mailing lists