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