[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20110406.224244.104071339.davem@davemloft.net>
Date:	Wed, 06 Apr 2011 22:42:44 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	hirofumi@...l.parknet.co.jp
Cc:	netdev@...r.kernel.org
Subject: Re: problem of "ipv4: revert Set rt->rt_iif more sanely on output
 routes."
From: David Miller <davem@...emloft.net>
Date: Wed, 06 Apr 2011 22:34:00 -0700 (PDT)
> From: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
> Date: Thu, 07 Apr 2011 13:31:06 +0900
> 
>> I'm not pretty sure though, output message is
>> 
>> 	ip_finish_output2: No header cache and no neighbour!
>> 
>> I'm not debugging this though,
>> 
>> static inline bool rt_is_output_route(struct rtable *rt)
>> {
>> 	return rt->rt_iif == 0;
>> }
>> 
>> from review I guess the above is one of cause.
> 
> arp_bind_neighbour() is only called if rt_is_output_route() is true
> or route is unicast.
> 
> If packet is sent using a route for which arp_bind_neighbour() has not
> been called, you will see that warning message.
Ok, the problem is that, for output routes in original code:
1) user's flow device index is stored in rt->rt_iif
2) arp_bind_neighbour() tests meanwhile used rt->fl.iif
So we do need, for now, to add a new member.  But I think for
correct semantics it needs to have inverse meaning to the one
you added in your RFC patch.
So fix is something like:
1) Add "int rt_route_iif;" to struct rtable
2) For input routes, always set rt_route_iif to same value as rt_iif
3) For output routes, always set rt_route_iif to zero.  Set rt_iif
   as it is done currently.
4) Change rt_is_{output,input}_route() to test rt_route_iif
This should fix the bug and not introduce new regressions.
Can you write and test such a patch with your test case?
Thank you!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists