From: "Justin P. Mattock" <justinmattock@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: ip_rt_bug: 10.0.0.52 -> 255.255.255.255, ?
Date: Sun, 14 Aug 2011 22:55:02 -0700 [thread overview]
Message-ID: <4E48B4B6.8000603@gmail.com> (raw)
In-Reply-To: <20110814.224536.1330937123770047026.davem@davemloft.net>
Oh.. guess I will wait for those to be put into the Mainline then.
Thanks for the info!
>
> First, please contact netdev@vger.kernel.org for networking issues.
>
> Second, this is fixed already:
>
> commit d547f727df86059104af2234804fdd538e112015
> Author: Julian Anastasov<ja@ssi.bg>
> Date: Sun Aug 7 22:20:20 2011 -0700
>
> ipv4: fix the reusing of routing cache entries
>
> compare_keys and ip_route_input_common rely on
> rt_oif for distinguishing of input and output routes
> with same keys values. But sometimes the input route has
> also same hash chain (keyed by iif != 0) with the output
> routes (keyed by orig_oif=0). Problem visible if running
> with small number of rhash_entries.
>
> Fix them to use rt_route_iif instead. By this way
> input route can not be returned to users that request
> output route.
>
> The patch fixes the ip_rt_bug errors that were
> reported in ip_local_out context, mostly for 255.255.255.255
> destinations.
>
> Signed-off-by: Julian Anastasov<ja@ssi.bg>
> Signed-off-by: David S. Miller<davem@davemloft.net>
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index e3dec1c..cb7efe0 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -731,6 +731,7 @@ static inline int compare_keys(struct rtable *rt1, struct rtable *rt2)
> ((__force u32)rt1->rt_key_src ^ (__force u32)rt2->rt_key_src) |
> (rt1->rt_mark ^ rt2->rt_mark) |
> (rt1->rt_key_tos ^ rt2->rt_key_tos) |
> + (rt1->rt_route_iif ^ rt2->rt_route_iif) |
> (rt1->rt_oif ^ rt2->rt_oif) |
> (rt1->rt_iif ^ rt2->rt_iif)) == 0;
> }
> @@ -2321,8 +2322,8 @@ int ip_route_input_common(struct sk_buff *skb, __be32 daddr, __be32 saddr,
> if ((((__force u32)rth->rt_key_dst ^ (__force u32)daddr) |
> ((__force u32)rth->rt_key_src ^ (__force u32)saddr) |
> (rth->rt_iif ^ iif) |
> - rth->rt_oif |
> (rth->rt_key_tos ^ tos)) == 0&&
> + rt_is_input_route(rth)&&
> rth->rt_mark == skb->mark&&
> net_eq(dev_net(rth->dst.dev), net)&&
> !rt_is_expired(rth)) {
>
>
>
next prev parent reply other threads:[~2011-08-15 5:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-15 3:56 ip_rt_bug: 10.0.0.52 -> 255.255.255.255, ? Justin P. Mattock
2011-08-15 5:45 ` David Miller
2011-08-15 5:55 ` Justin P. Mattock [this message]
2011-08-15 5:56 ` David Miller
2011-08-15 6:09 ` Justin P. Mattock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E48B4B6.8000603@gmail.com \
--to=justinmattock@gmail.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.