Hi,
On Wed, Apr 29, 2015 at 11:28:46AM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Tue, 28 Apr 2015, Martin KaFai Lau wrote:
>
> > -static inline struct in6_addr *rt6_nexthop(struct rt6_info *rt)
> > +static inline struct in6_addr *rt6_nexthop(struct rt6_info *rt,
> > + struct in6_addr *daddr)
> > {
> > - return &rt->rt6i_gateway;
> > + return (rt->rt6i_flags & RTF_GATEWAY) ? &rt->rt6i_gateway : daddr;
> > }
>
> Similar change in ipv4 caused problem for places
> that request route to one nexthop but later the transmitted
> IP header contains different destination. Such examples
> were:
>
> - net/ipv4/raw.c when hdrincl is used
> - xt_TEE.c: I see that it has IPv6 support
> - IPVS: request route to real server but send packet with
> daddr=virtual IP (Direct Route method)
>
> For IPv4 link routes, callers can get a route
> with rt_gateway=0 and rt_nexthop() can return daddr from
> header.
>
> We then solved it with FLOWI_FLAG_KNOWN_NH flag which
> forces a cached route where rt_gateway is filled with requested
> nexthop address:
>
> commit c27c9322d015
> commit 2ad5b9e4bd31
> commit ad4d3ef8b7eb
>
> Can you check if this series causes the same
> problem for net/ipv6/raw.c (hdrincl=1), xt_TEE.c. IPVS code is
> in __ip_vs_get_out_rt_v6() where the route is resolved
> and then attached to skb with skb_dst_set_noref().
Thanks for the pointers.
I have looked around and I can see your points. I think we can mostly mimic
the IPv4 approach here. After a quick thought, one hurdle is in the
dst_check() since the rt6 does not have the genid like rt4 does. It is removed
from rt6_info at some point to fix another perf bug, iirc. I will try some
ways without re-introducing genid.
--Martin
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
