I have hit something similar in the past, and _I think_ the patch is
already Mainline, but dont remember seeing ip_rt_bug.
Anyways just so people are aware.
dmesg here:
http://fpaste.org/Fgo0/
[33184.395947] ip_rt_bug: 10.0.0.52 -> 255.255.255.255, ?
[33184.395960] ------------[ cut here ]------------
[33184.395969] WARNING: at net/ipv4/route.c:1717 ip_rt_bug+0x5c/0x62()
[33184.395973] Hardware name: MacBookPro2,2
[33184.395976] Modules linked in: hidp fuse cpufreq_ondemand
acpi_cpufreq freq_table mperf 8021q garp stp llc ipt_REJECT
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter
ip_tables rfcomm bnep arc4 ath9k mac80211 ath9k_common ath9k_hw ath
cfg80211 ecb btusb bluetooth radeon ttm drm_kms_helper drm uvcvideo
iTCO_wdt microcode i2c_i801 joydev apple_bl videodev appletouch
i2c_algo_bit rfkill sky2 video applesmc input_polldev
iTCO_vendor_support v4l2_compat_ioctl32 i2c_core [last unloaded:
scsi_wait_scan]
[33184.396177] Pid: 10739, comm: gcm-session Not tainted
3.1.0-rc1-00073-g068ef73 #4
[33184.396183] Call Trace:
[33184.396195] [<ffffffff81050d3c>] warn_slowpath_common+0x83/0x9b
[33184.396205] [<ffffffff81050d6e>] warn_slowpath_null+0x1a/0x1c
[33184.396213] [<ffffffff81434d5b>] ip_rt_bug+0x5c/0x62
[33184.396221] [<ffffffff8143ceff>] dst_output+0x19/0x1d
[33184.396229] [<ffffffff8143e354>] ip_local_out+0x20/0x24
[33184.396237] [<ffffffff8143f1b9>] ip_send_skb+0x18/0x3e
[33184.396246] [<ffffffff8145b3f2>] udp_send_skb+0x239/0x29b
[33184.396255] [<ffffffff8145cb87>] udp_sendmsg+0x5b7/0x82e
[33184.396265] [<ffffffff813fe07b>] ? release_sock+0x35/0x155
[33184.396272] [<ffffffff8143cc44>] ? ip_select_ident+0x3d/0x3d
[33184.396282] [<ffffffff81056d5b>] ? local_bh_enable_ip+0xe/0x10
[33184.396293] [<ffffffff814bbeba>] ? _raw_spin_unlock_bh+0x40/0x44
[33184.396301] [<ffffffff813fe192>] ? release_sock+0x14c/0x155
[33184.396312] [<ffffffff8146402c>] inet_sendmsg+0x66/0x6f
[33184.396321] [<ffffffff813fa3e7>] sock_sendmsg+0xe6/0x109
[33184.396330] [<ffffffff81081dc3>] ? lock_acquire+0x122/0x15b
[33184.396339] [<ffffffff810f4cde>] ? might_fault+0x5c/0xac
[33184.396347] [<ffffffff81081c6a>] ? lock_release+0x1ab/0x1e2
[33184.396356] [<ffffffff810f4d27>] ? might_fault+0xa5/0xac
[33184.396364] [<ffffffff813f8c6e>] ? copy_from_user+0x2f/0x31
[33184.396374] [<ffffffff813fc1b0>] sys_sendto+0x12f/0x171
[33184.396384] [<ffffffff814c2cba>] ? sysret_check+0x2e/0x69
[33184.396392] [<ffffffff810821f9>] ? trace_hardirqs_on_caller+0x121/0x158
[33184.396401] [<ffffffff810a4b43>] ? audit_syscall_entry+0x11c/0x148
[33184.396410] [<ffffffff8123e69e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[33184.396419] [<ffffffff814c2c82>] system_call_fastpath+0x16/0x1b
[33184.396426] ---[ end trace 5fddb97ae7a1760a ]---
[33185.493453] ip_rt_bug: 10.0.0.52 -> 255.255.255.255, ?
[33185.493464] ------------[ cut here ]------------
[33185.493471] WARNING: at net/ipv4/route.c:1717 ip_rt_bug+0x5c/0x62()
[33185.493474] Hardware name: MacBookPro2,2
[33185.493476] Modules linked in: hidp fuse cpufreq_ondemand
acpi_cpufreq freq_table mperf 8021q garp stp llc ipt_REJECT
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter
ip_tables rfcomm bnep arc4 ath9k mac80211 ath9k_common ath9k_hw ath
cfg80211 ecb btusb bluetooth radeon ttm drm_kms_helper drm uvcvideo
iTCO_wdt microcode i2c_i801 joydev apple_bl videodev appletouch
i2c_algo_bit rfkill sky2 video applesmc input_polldev
iTCO_vendor_support v4l2_compat_ioctl32 i2c_core [last unloaded:
scsi_wait_scan]
[33185.493545] Pid: 10739, comm: gcm-session Tainted: G W
3.1.0-rc1-00073-g068ef73 #4
[33185.493549] Call Trace:
[33185.493556] [<ffffffff81050d3c>] warn_slowpath_common+0x83/0x9b
[33185.493562] [<ffffffff81050d6e>] warn_slowpath_null+0x1a/0x1c
[33185.493566] [<ffffffff81434d5b>] ip_rt_bug+0x5c/0x62
[33185.493571] [<ffffffff8143ceff>] dst_output+0x19/0x1d
[33185.493575] [<ffffffff8143e354>] ip_local_out+0x20/0x24
[33185.493579] [<ffffffff8143f1b9>] ip_send_skb+0x18/0x3e
[33185.493584] [<ffffffff8145b3f2>] udp_send_skb+0x239/0x29b
[33185.493589] [<ffffffff8145cb87>] udp_sendmsg+0x5b7/0x82e
[33185.493594] [<ffffffff813fe07b>] ? release_sock+0x35/0x155
[33185.493598] [<ffffffff8143cc44>] ? ip_select_ident+0x3d/0x3d
[33185.493603] [<ffffffff81056d5b>] ? local_bh_enable_ip+0xe/0x10
[33185.493609] [<ffffffff814bbeba>] ? _raw_spin_unlock_bh+0x40/0x44
[33185.493613] [<ffffffff813fe192>] ? release_sock+0x14c/0x155
[33185.493617] [<ffffffff8146402c>] inet_sendmsg+0x66/0x6f
[33185.493623] [<ffffffff813fa3e7>] sock_sendmsg+0xe6/0x109
[33185.493628] [<ffffffff81081dc3>] ? lock_acquire+0x122/0x15b
[33185.493633] [<ffffffff810f4cde>] ? might_fault+0x5c/0xac
[33185.493637] [<ffffffff81081c6a>] ? lock_release+0x1ab/0x1e2
[33185.493642] [<ffffffff810f4d27>] ? might_fault+0xa5/0xac
[33185.493646] [<ffffffff813f8c6e>] ? copy_from_user+0x2f/0x31
[33185.493650] [<ffffffff813fc1b0>] sys_sendto+0x12f/0x171
[33185.493655] [<ffffffff814c2cba>] ? sysret_check+0x2e/0x69
[33185.493659] [<ffffffff810821f9>] ? trace_hardirqs_on_caller+0x121/0x158
[33185.493664] [<ffffffff810a4b43>] ? audit_syscall_entry+0x11c/0x148
[33185.493670] [<ffffffff8123e69e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[33185.493674] [<ffffffff814c2c82>] system_call_fastpath+0x16/0x1b
[33185.493677] ---[ end trace 5fddb97ae7a1760b ]---
Justin P. Mattock
From: "Justin P. Mattock" <[email protected]>
Date: Sun, 14 Aug 2011 22:55:02 -0700
> Oh.. guess I will wait for those to be put into the Mainline
> then. Thanks for the info!
It is in mainline.
First, please contact [email protected] for networking issues.
Second, this is fixed already:
commit d547f727df86059104af2234804fdd538e112015
Author: Julian Anastasov <[email protected]>
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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
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)) {
On 08/14/2011 10:56 PM, David Miller wrote:
> From: "Justin P. Mattock"<[email protected]>
> Date: Sun, 14 Aug 2011 22:55:02 -0700
>
>> Oh.. guess I will wait for those to be put into the Mainline
>> then. Thanks for the info!
>
> It is in mainline.
>
alright.. I see it now. I pulled on thurs/fri but never went any further
with the build after that. will clean and build when I get a chance and
run it.
Thanks again!
Justin P. Mattock
Oh.. guess I will wait for those to be put into the Mainline then.
Thanks for the info!
>
> First, please contact [email protected] for networking issues.
>
> Second, this is fixed already:
>
> commit d547f727df86059104af2234804fdd538e112015
> Author: Julian Anastasov<[email protected]>
> 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<[email protected]>
> Signed-off-by: David S. Miller<[email protected]>
>
> 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)) {
>
>
>