[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1210082259180.12172@ja.ssi.bg>
Date: Mon, 8 Oct 2012 23:43:45 +0300 (EEST)
From: Julian Anastasov <ja@....bg>
To: David Miller <davem@...emloft.net>
cc: netdev@...r.kernel.org
Subject: Re: [PATCH net 1/6] ipv4: fix sending of redirects
Hello,
On Mon, 8 Oct 2012, David Miller wrote:
> From: Julian Anastasov <ja@....bg>
> Date: Sun, 7 Oct 2012 14:26:03 +0300
>
> > @@ -322,7 +322,8 @@ int fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst,
> > {
> > int r = secpath_exists(skb) ? 0 : IN_DEV_RPFILTER(idev);
> >
> > - if (!r && !fib_num_tclassid_users(dev_net(dev))) {
> > + if (!r && !fib_num_tclassid_users(dev_net(dev)) &&
> > + dev->ifindex != oif) {
> > *itag = 0;
> > return 0;
> > }
>
> Hmmm, won't this cause the slow path to be taken for locally
> destined traffic?
In this case idev=eth0 and oif=lo. The only case
where we can see same input and output device is for
forwarding and loopback (but only output routes where
there is no such validation).
Of course, it slows down on traffic that ignores
our redirects. We can save some cycles if IN_DEV_TX_REDIRECTS
is checked before setting RTCF_DOREDIRECT:
(dev->ifindex != oif || !IN_DEV_TX_REDIRECTS(idev)) {
RTCF_DOREDIRECT is used just to call ip_rt_send_redirect
where all depends on IN_DEV_TX_REDIRECTS.
The only difference can be that user space will
not see RTCF_DOREDIRECT flag if IN_DEV_TX_REDIRECTS is false.
But may be it is better to show "redirect" in ip route
only when IN_DEV_TX_REDIRECTS are enabled. The old way
is preferred only when there is routing cache and changes
in IN_DEV_TX_REDIRECTS do not flush cache in devinet_conf_proc().
> > + rt->rt_gateway ? : ip_hdr(skb)->daddr);
>
> Please use the rt_nexthop() helper.
>
> > + __be32 gw = rt->rt_gateway ? : ip_hdr(skb)->daddr;
Good idea.
Regards
--
Julian Anastasov <ja@....bg>
--
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