* ip_rt_bug route.c:1677 in 3.0
@ 2011-09-06 20:45 Andi Kleen
2011-09-06 20:51 ` David Miller
2011-09-06 21:01 ` Eric Dumazet
0 siblings, 2 replies; 4+ messages in thread
From: Andi Kleen @ 2011-09-06 20:45 UTC (permalink / raw)
To: netdev
FYI,
My 3.0 workstation just spew:
I wonder if a application could have caused this?
ip_rt_bug: 10.7.201.108 -> 255.255.255.255, ?
------------[ cut here ]------------
WARNING: at /home/ak/lsrc/git/linux-2.6/net/ipv4/route.c:1677 ip_rt_bug+0x5f/0x70()
Hardware name: ...
Modules linked in: vfat fat nls_utf8 udf ses enclosure nfs lockd fscache auth_rpcgss nfs_acl fuse sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 kvm_intel kvm uinput snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm iTCO_wdt microcode e1000 snd_timer snd soundcore broadcom iTCO_vendor_support tg3 i7core_edac edac_core snd_page_alloc i2c_i801 dcdbas serio_raw joydev pcspkr firewire_ohci firewire_core crc_itu_t usb_storage radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
Pid: 28530, comm: xsane Not tainted 3.0.0+ #15
Call Trace:
[<ffffffff810510ef>] warn_slowpath_common+0x7f/0xc0
[<ffffffff8105114a>] warn_slowpath_null+0x1a/0x20
[<ffffffff814946cf>] ip_rt_bug+0x5f/0x70
[<ffffffff8149f149>] ip_local_out+0x29/0x30
[<ffffffff814a047b>] ip_send_skb+0x1b/0x70
[<ffffffff814c25fa>] udp_send_skb+0x11a/0x3b0
[<ffffffff8149d3d0>] ? ip_setup_cork+0x170/0x170
[<ffffffff814c475c>] udp_sendmsg+0x37c/0x9b0
[<ffffffff814c31b9>] ? udp_lib_get_port+0x2a9/0x3e0
[<ffffffff81528d25>] ? _raw_spin_unlock_bh+0x15/0x20
[<ffffffff81448ca3>] ? release_sock+0xe3/0x110
[<ffffffff814ce214>] inet_sendmsg+0x64/0xb0
[<ffffffff81443e19>] sock_sendmsg+0xe9/0x120
[<ffffffff8111bb74>] ? handle_pte_fault+0x84/0x980
[<ffffffff8112be91>] ? free_pages_and_swap_cache+0xb1/0xe0
[<ffffffff812750cd>] ? cpumask_any_but+0x2d/0x40
[<ffffffff814464d1>] ? move_addr_to_kernel+0x71/0x80
[<ffffffff81446f39>] sys_sendto+0x139/0x190
[<ffffffff8144b20e>] ? sock_setsockopt+0x1ae/0x790
[<ffffffff811511ed>] ? fd_install+0x3d/0x70
[<ffffffff814471f3>] ? sys_setsockopt+0xb3/0xc0
[<ffffffff8153092b>] system_call_fastpath+0x16/0x1b
---[ end trace ada1d01fefb0d73c ]---
ip_rt_bug: 10.7.201.108 -> 255.255.255.255, ?
------------[ cut here ]------------
WARNING: at /home/ak/lsrc/git/linux-2.6/net/ipv4/route.c:1677 ip_rt_bug+0x5f/0x70()
Hardware name: ...
Modules linked in: vfat fat nls_utf8 udf ses enclosure nfs lockd fscache auth_rpcgss nfs_acl fuse sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 kvm_intel kvm uinput snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm iTCO_wdt microcode e1000 snd_timer snd soundcore broadcom iTCO_vendor_support tg3 i7core_edac edac_core snd_page_alloc i2c_i801 dcdbas serio_raw joydev pcspkr firewire_ohci firewire_core crc_itu_t usb_storage radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
Pid: 28530, comm: xsane Tainted: G W 3.0.0+ #15
Call Trace:
[<ffffffff810510ef>] warn_slowpath_common+0x7f/0xc0
[<ffffffff8105114a>] warn_slowpath_null+0x1a/0x20
[<ffffffff814946cf>] ip_rt_bug+0x5f/0x70
[<ffffffff8149f149>] ip_local_out+0x29/0x30
[<ffffffff814a047b>] ip_send_skb+0x1b/0x70
[<ffffffff814c25fa>] udp_send_skb+0x11a/0x3b0
[<ffffffff8149d3d0>] ? ip_setup_cork+0x170/0x170
[<ffffffff814c475c>] udp_sendmsg+0x37c/0x9b0
[<ffffffff814c31b9>] ? udp_lib_get_port+0x2a9/0x3e0
[<ffffffff81528d25>] ? _raw_spin_unlock_bh+0x15/0x20
[<ffffffff81448ca3>] ? release_sock+0xe3/0x110
[<ffffffff814ce214>] inet_sendmsg+0x64/0xb0
[<ffffffff81443e19>] sock_sendmsg+0xe9/0x120
...
--
ak@linux•intel.com -- Speaking for myself only
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ip_rt_bug route.c:1677 in 3.0
2011-09-06 20:45 ip_rt_bug route.c:1677 in 3.0 Andi Kleen
@ 2011-09-06 20:51 ` David Miller
2011-09-06 20:55 ` Andi Kleen
2011-09-06 21:01 ` Eric Dumazet
1 sibling, 1 reply; 4+ messages in thread
From: David Miller @ 2011-09-06 20:51 UTC (permalink / raw)
To: andi; +Cc: netdev
From: Andi Kleen <andi@firstfloor•org>
Date: Tue, 6 Sep 2011 13:45:45 -0700
> My 3.0 workstation just spew:
"3.0.what?"
> I wonder if a application could have caused this?
It's the routing cache hashing bug, fixed by:
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)) {
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: ip_rt_bug route.c:1677 in 3.0
2011-09-06 20:51 ` David Miller
@ 2011-09-06 20:55 ` Andi Kleen
0 siblings, 0 replies; 4+ messages in thread
From: Andi Kleen @ 2011-09-06 20:55 UTC (permalink / raw)
To: David Miller; +Cc: andi, netdev
On Tue, Sep 06, 2011 at 04:51:35PM -0400, David Miller wrote:
> From: Andi Kleen <andi@firstfloor•org>
> Date: Tue, 6 Sep 2011 13:45:45 -0700
>
> > My 3.0 workstation just spew:
>
> "3.0.what?"
3.0.0 + some local changes unrelated to network.
>
> > I wonder if a application could have caused this?
>
> It's the routing cache hashing bug, fixed by:
Thanks.
-Andi
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ip_rt_bug route.c:1677 in 3.0
2011-09-06 20:45 ip_rt_bug route.c:1677 in 3.0 Andi Kleen
2011-09-06 20:51 ` David Miller
@ 2011-09-06 21:01 ` Eric Dumazet
1 sibling, 0 replies; 4+ messages in thread
From: Eric Dumazet @ 2011-09-06 21:01 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev
Le mardi 06 septembre 2011 à 13:45 -0700, Andi Kleen a écrit :
> FYI,
>
> My 3.0 workstation just spew:
>
> I wonder if a application could have caused this?
>
> ip_rt_bug: 10.7.201.108 -> 255.255.255.255, ?
> ------------[ cut here ]------------
> WARNING: at /home/ak/lsrc/git/linux-2.6/net/ipv4/route.c:1677 ip_rt_bug+0x5f/0x70()
> Hardware name: ...
> Modules linked in: vfat fat nls_utf8 udf ses enclosure nfs lockd fscache auth_rpcgss nfs_acl fuse sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 kvm_intel kvm uinput snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm iTCO_wdt microcode e1000 snd_timer snd soundcore broadcom iTCO_vendor_support tg3 i7core_edac edac_core snd_page_alloc i2c_i801 dcdbas serio_raw joydev pcspkr firewire_ohci firewire_core crc_itu_t usb_storage radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
> Pid: 28530, comm: xsane Not tainted 3.0.0+ #15
> Call Trace:
> [<ffffffff810510ef>] warn_slowpath_common+0x7f/0xc0
> [<ffffffff8105114a>] warn_slowpath_null+0x1a/0x20
> [<ffffffff814946cf>] ip_rt_bug+0x5f/0x70
> [<ffffffff8149f149>] ip_local_out+0x29/0x30
> [<ffffffff814a047b>] ip_send_skb+0x1b/0x70
> [<ffffffff814c25fa>] udp_send_skb+0x11a/0x3b0
> [<ffffffff8149d3d0>] ? ip_setup_cork+0x170/0x170
> [<ffffffff814c475c>] udp_sendmsg+0x37c/0x9b0
> [<ffffffff814c31b9>] ? udp_lib_get_port+0x2a9/0x3e0
> [<ffffffff81528d25>] ? _raw_spin_unlock_bh+0x15/0x20
> [<ffffffff81448ca3>] ? release_sock+0xe3/0x110
> [<ffffffff814ce214>] inet_sendmsg+0x64/0xb0
> [<ffffffff81443e19>] sock_sendmsg+0xe9/0x120
> [<ffffffff8111bb74>] ? handle_pte_fault+0x84/0x980
> [<ffffffff8112be91>] ? free_pages_and_swap_cache+0xb1/0xe0
> [<ffffffff812750cd>] ? cpumask_any_but+0x2d/0x40
> [<ffffffff814464d1>] ? move_addr_to_kernel+0x71/0x80
> [<ffffffff81446f39>] sys_sendto+0x139/0x190
> [<ffffffff8144b20e>] ? sock_setsockopt+0x1ae/0x790
> [<ffffffff811511ed>] ? fd_install+0x3d/0x70
> [<ffffffff814471f3>] ? sys_setsockopt+0xb3/0xc0
> [<ffffffff8153092b>] system_call_fastpath+0x16/0x1b
> ---[ end trace ada1d01fefb0d73c ]---
> ip_rt_bug: 10.7.201.108 -> 255.255.255.255, ?
> ------------[ cut here ]------------
> WARNING: at /home/ak/lsrc/git/linux-2.6/net/ipv4/route.c:1677 ip_rt_bug+0x5f/0x70()
> Hardware name: ...
> Modules linked in: vfat fat nls_utf8 udf ses enclosure nfs lockd fscache auth_rpcgss nfs_acl fuse sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 kvm_intel kvm uinput snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm iTCO_wdt microcode e1000 snd_timer snd soundcore broadcom iTCO_vendor_support tg3 i7core_edac edac_core snd_page_alloc i2c_i801 dcdbas serio_raw joydev pcspkr firewire_ohci firewire_core crc_itu_t usb_storage radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
> Pid: 28530, comm: xsane Tainted: G W 3.0.0+ #15
> Call Trace:
> [<ffffffff810510ef>] warn_slowpath_common+0x7f/0xc0
> [<ffffffff8105114a>] warn_slowpath_null+0x1a/0x20
> [<ffffffff814946cf>] ip_rt_bug+0x5f/0x70
> [<ffffffff8149f149>] ip_local_out+0x29/0x30
> [<ffffffff814a047b>] ip_send_skb+0x1b/0x70
> [<ffffffff814c25fa>] udp_send_skb+0x11a/0x3b0
> [<ffffffff8149d3d0>] ? ip_setup_cork+0x170/0x170
> [<ffffffff814c475c>] udp_sendmsg+0x37c/0x9b0
> [<ffffffff814c31b9>] ? udp_lib_get_port+0x2a9/0x3e0
> [<ffffffff81528d25>] ? _raw_spin_unlock_bh+0x15/0x20
> [<ffffffff81448ca3>] ? release_sock+0xe3/0x110
> [<ffffffff814ce214>] inet_sendmsg+0x64/0xb0
> [<ffffffff81443e19>] sock_sendmsg+0xe9/0x120
> ...
>
>
Make sure you have this commit
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-09-06 21:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-06 20:45 ip_rt_bug route.c:1677 in 3.0 Andi Kleen
2011-09-06 20:51 ` David Miller
2011-09-06 20:55 ` Andi Kleen
2011-09-06 21:01 ` Eric Dumazet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox