Hello, On Mon, 21 Oct 2013, Hannes Frederic Sowa wrote: > Not related to the patch: > > That reminds me that Yoshifuji had the idea to cache the results for > ipv6_addr_type in IP6CB to avoid calling this function over and over again. > Maybe we can do the same for rt6_infos to save some cycles here and there. Yes, ipv6_addr_type has little price. May be only DNAT and IPSec can complicate such caching. > Also, what do you think about this site: > > net/ipv6/ip6_output.c: > 411 > 412 rt = (struct rt6_info *) dst; > 413 if (rt->rt6i_flags & RTF_GATEWAY) > 414 target = &rt->rt6i_gateway; > 415 else > 416 target = &hdr->daddr; > 417 > > Our provided skb_dst should come from ip6_route_input, thus ip6_pol_route. So > I assume we have rt6i_gateway == hdr->daddr there, too. It is a bit more > complicated because of possible routing extension headers. Maybe you already > looked at this already? Yes, I checked every site that uses rt6i_gateway but not with the perspective to use rt6_nexthop(). It seems this is a rt6_nexthop() candidate. > I just found it while searching which other code paths do emit packets > while xt_TEE is processing (generation of redirects) and could also lead > to stack exhaustion. But the path in ip6_forward seems fine. Yes. I found only one place more dangerous: fib6_add_rt2node(). But I think its checks are still valid. Regards -- Julian Anastasov <ja@xxxxxx> -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
