* Re: Slab corruption mm3 + davem fixes [not found] <20030511031940.97C24251B@oscar.casa.dyndns.org> @ 2003-05-11 16:21 ` Ed Tomlinson [not found] ` <1052690490.4471.2.camel@rth.ninka.net> 0 siblings, 1 reply; 6+ messages in thread From: Ed Tomlinson @ 2003-05-11 16:21 UTC (permalink / raw) To: akpm, davem, linux-mm; +Cc: linux-kernel Hi, I am also seeing this on 69-bk (as of Sunday morning) Ed On May 10, 2003 11:19 pm, Ed Tomlinson wrote: > Hi, > > I looked at my logs and found the following error in it. My kernel is > 69-mm3 with two davem fixes on it. > > May 10 22:41:06 oscar kernel: > *************************************************************************** >********** > *************************************************************************** >**************************************** > *************************************************************************** >**************************************** > *************************************************************************** >**************************************** > *************************************************************************** >**************************************** > *************************************************************************** >**************************************** > *************************************************************************** >**************************************** > *************************************************************************** >**************************************** > *************************************************************************** >****************************** May 10 22:41:06 oscar kernel: > **********************************************************************A5 > May 10 22:41:06 oscar kernel: Call Trace: > May 10 22:41:06 oscar kernel: [__slab_error+30/32] __slab_error+0x1e/0x20 > May 10 22:41:06 oscar kernel: [check_poison_obj+376/384] > check_poison_obj+0x178/0x180 May 10 22:41:06 oscar kernel: > [kmalloc+221/392] kmalloc+0xdd/0x188 May 10 22:41:06 oscar kernel: > [alloc_skb+64/240] alloc_skb+0x40/0xf0 May 10 22:41:06 oscar kernel: > [alloc_skb+64/240] alloc_skb+0x40/0xf0 May 10 22:41:06 oscar kernel: > [skb_copy+45/204] skb_copy+0x2d/0xcc May 10 22:41:06 oscar kernel: > [_end+615445203/1070187180] skb_ip_make_writable+0xcf/0x164 [iptable_nat] > May 10 22:41:06 oscar kernel: [cache_init_objs+71/308] > cache_init_objs+0x47/0x134 May 10 22:41:06 oscar kernel: > [_end+615444563/1070187180] icmp_reply_translation+0x33/0x1e4 [iptable_nat] > May 10 22:41:06 oscar kernel: [_end+615450270/1070187180] > gcc2_compiled.+0xc2/0x1d8 [iptable_nat] May 10 22:41:06 oscar kernel: > [_end+615450641/1070187180] ip_nat_out+0x5d/0x64 [iptable_nat] May 10 > 22:41:06 oscar kernel: [ip_finish_output2+0/416] > ip_finish_output2+0x0/0x1a0 May 10 22:41:06 oscar kernel: > [nf_iterate+63/156] nf_iterate+0x3f/0x9c May 10 22:41:06 oscar kernel: > [ip_finish_output2+0/416] ip_finish_output2+0x0/0x1a0 May 10 22:41:06 oscar > kernel: [nf_hook_slow+149/296] nf_hook_slow+0x95/0x128 May 10 22:41:06 > oscar kernel: [ip_finish_output2+0/416] ip_finish_output2+0x0/0x1a0 May 10 > 22:41:06 oscar kernel: [_end+615462636/1070187180] ip_nat_out_ops+0x0/0x1c > [iptable_nat] May 10 22:41:06 oscar kernel: [ip_output+535/544] > ip_output+0x217/0x220 May 10 22:41:06 oscar kernel: > [ip_finish_output2+0/416] ip_finish_output2+0x0/0x1a0 May 10 22:41:06 oscar > kernel: [nf_hook_slow+149/296] nf_hook_slow+0x95/0x128 May 10 22:41:06 > oscar kernel: [ip_forward_finish+39/60] ip_forward_finish+0x27/0x3c May 10 > 22:41:06 oscar kernel: [nf_hook_slow+208/296] nf_hook_slow+0xd0/0x128 May > 10 22:41:06 oscar kernel: [ip_forward+490/564] ip_forward+0x1ea/0x234 May > 10 22:41:06 oscar kernel: [ip_forward_finish+0/60] > ip_forward_finish+0x0/0x3c May 10 22:41:06 oscar kernel: > [ip_rcv_finish+441/512] ip_rcv_finish+0x1b9/0x200 May 10 22:41:06 oscar > kernel: [nf_hook_slow+208/296] nf_hook_slow+0xd0/0x128 May 10 22:41:06 > oscar kernel: [ip_rcv+924/984] ip_rcv+0x39c/0x3d8 May 10 22:41:06 oscar > kernel: [ip_rcv_finish+0/512] ip_rcv_finish+0x0/0x200 May 10 22:41:06 > oscar kernel: [netif_receive_skb+283/332] netif_receive_skb+0x11b/0x14c > May 10 22:41:06 oscar kernel: [process_backlog+113/292] > process_backlog+0x71/0x124 May 10 22:41:06 oscar kernel: > [net_rx_action+114/328] net_rx_action+0x72/0x148 May 10 22:41:06 oscar > kernel: [do_softirq+82/172] do_softirq+0x52/0xac May 10 22:41:06 oscar > kernel: [local_bh_enable+82/108] local_bh_enable+0x52/0x6c May 10 22:41:06 > oscar kernel: [_end+614250407/1070187180] ppp_asynctty_receive+0x4f/0x84 > [ppp_async] May 10 22:41:06 oscar kernel: [pty_write+237/336] > pty_write+0xed/0x150 May 10 22:41:06 oscar kernel: [write_chan+424/516] > write_chan+0x1a8/0x204 May 10 22:41:06 oscar kernel: > [default_wake_function+0/24] default_wake_function+0x0/0x18 May 10 22:41:06 > oscar kernel: [default_wake_function+0/24] default_wake_function+0x0/0x18 > May 10 22:41:06 oscar kernel: [tty_write+515/708] tty_write+0x203/0x2c4 > May 10 22:41:06 oscar kernel: [write_chan+0/516] write_chan+0x0/0x204 May > 10 22:41:06 oscar kernel: [vfs_write+162/208] vfs_write+0xa2/0xd0 May 10 > 22:41:06 oscar kernel: [sys_write+46/76] sys_write+0x2e/0x4c May 10 > 22:41:06 oscar kernel: [syscall_call+7/11] syscall_call+0x7/0xb May 10 > 22:41:06 oscar kernel: > > And with an ipchains based firewall: > > May 9 19:55:54 oscar kernel: > *************************************************************************** >********** > *************************************************************************** >**************************************** > *************************************************************************** >**************************************** > *************************************************************************** >**************************************** > *************************************************************************** >**************************************** > *************************************************************************** >**************************************** > *************************************************************************** >**************************************** > *************************************************************************** >**************************************** > *************************************************************************** >****************************** May 9 19:55:54 oscar kernel: > **********************************************************************A5 > May 9 19:55:54 oscar kernel: Call Trace: > May 9 19:55:55 oscar kernel: [__slab_error+30/32] __slab_error+0x1e/0x20 > May 9 19:55:55 oscar kernel: [check_poison_obj+376/384] > check_poison_obj+0x178/0x180 May 9 19:55:55 oscar kernel: > [kmalloc+221/392] kmalloc+0xdd/0x188 May 9 19:55:55 oscar kernel: > [alloc_skb+64/240] alloc_skb+0x40/0xf0 May 9 19:55:55 oscar kernel: > [alloc_skb+64/240] alloc_skb+0x40/0xf0 May 9 19:55:55 oscar kernel: > [_end+547372157/1070273676] icmp_manip_pkt+0x45/0x64 [ipchains] May 9 > 19:55:55 oscar kernel: [skb_copy+45/204] skb_copy+0x2d/0xcc May 9 > 19:55:55 oscar kernel: [_end+547367523/1070273676] > skb_ip_make_writable+0xcf/0x164 [ipchains] May 9 19:55:55 oscar kernel: > [_end+547367236/1070273676] icmp_reply_translation+0x194/0x1e4 [ipchains] > May 9 19:55:55 oscar kernel: [_end+547366883/1070273676] > icmp_reply_translation+0x33/0x1e4 [ipchains] May 9 19:55:55 oscar kernel: > [_end+547362523/1070273676] check_for_demasq+0xbb/0x1bc [ipchains] May 9 > 19:55:55 oscar kernel: [_end+547400300/1070273676] > ip_conntrack_protocol_icmp+0x0/0x40 [ipchains] May 9 19:55:55 oscar > kernel: [_end+547359450/1070273676] fw_in+0x162/0x2b8 [ipchains] May 9 > 19:55:55 oscar kernel: [_end+547400948/1070273676] ipfw_ops+0x0/0x18 > [ipchains] May 9 19:55:55 oscar kernel: [_end+547359672/1070273676] > fw_in+0x240/0x2b8 [ipchains] May 9 19:55:55 oscar kernel: > [nf_iterate+63/156] nf_iterate+0x3f/0x9c May 9 19:55:55 oscar kernel: > [ip_rcv_finish+0/512] ip_rcv_finish+0x0/0x200 May 9 19:55:55 oscar kernel: > [nf_hook_slow+149/296] nf_hook_slow+0x95/0x128 May 9 19:55:55 oscar > kernel: [ip_rcv_finish+0/512] ip_rcv_finish+0x0/0x200 May 9 19:55:55 > oscar kernel: [_end+547400364/1070273676] preroute_ops+0x0/0x1c [ipchains] > May 9 19:55:55 oscar kernel: [ip_rcv+924/984] ip_rcv+0x39c/0x3d8 May 9 > 19:55:55 oscar kernel: [ip_rcv_finish+0/512] ip_rcv_finish+0x0/0x200 May > 9 19:55:55 oscar kernel: [netif_receive_skb+283/332] > netif_receive_skb+0x11b/0x14c May 9 19:55:55 oscar kernel: > [process_backlog+113/292] process_backlog+0x71/0x124 May 9 19:55:55 oscar > kernel: [net_rx_action+114/328] net_rx_action+0x72/0x148 May 9 19:55:55 > oscar kernel: [do_softirq+82/172] do_softirq+0x52/0xac May 9 19:55:55 > oscar kernel: [local_bh_enable+82/108] local_bh_enable+0x52/0x6c May 9 > 19:55:55 oscar kernel: [_end+547215751/1070273676] > ppp_asynctty_receive+0x4f/0x84 [ppp_async] May 9 19:55:55 oscar kernel: > [pty_write+237/336] pty_write+0xed/0x150 May 9 19:55:55 oscar kernel: > [write_chan+424/516] write_chan+0x1a8/0x204 May 9 19:55:55 oscar kernel: > [default_wake_function+0/24] default_wake_function+0x0/0x18 May 9 19:55:55 > oscar kernel: [default_wake_function+0/24] default_wake_function+0x0/0x18 > May 9 19:55:55 oscar kernel: [tty_write+515/708] tty_write+0x203/0x2c4 > May 9 19:55:55 oscar kernel: [write_chan+0/516] write_chan+0x0/0x204 May > 9 19:55:55 oscar kernel: [vfs_write+162/208] vfs_write+0xa2/0xd0 May 9 > 19:55:55 oscar kernel: [sys_write+46/76] sys_write+0x2e/0x4c May 9 > 19:55:55 oscar kernel: [syscall_call+7/11] syscall_call+0x7/0xb May 9 > 19:55:55 oscar kernel: > > Hope this helps, > Ed Tomlinson > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a> ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <1052690490.4471.2.camel@rth.ninka.net>]
* Re: Slab corruption mm3 + davem fixes [not found] ` <1052690490.4471.2.camel@rth.ninka.net> @ 2003-05-11 22:15 ` Andrew Morton 2003-05-11 21:24 ` David S. Miller 2003-05-11 22:34 ` David S. Miller 0 siblings, 2 replies; 6+ messages in thread From: Andrew Morton @ 2003-05-11 22:15 UTC (permalink / raw) To: David S. Miller; +Cc: tomlins, linux-mm, linux-kernel, rusty, laforge "David S. Miller" <davem@redhat.com> wrote: > > On Sun, 2003-05-11 at 09:21, Ed Tomlinson wrote: > > I am also seeing this on 69-bk (as of Sunday morning) > ... > > On May 10, 2003 11:19 pm, Ed Tomlinson wrote: > > > I looked at my logs and found the following error in it. My kernel is > > > 69-mm3 with two davem fixes on it. > ... > > > May 10 22:41:06 oscar kernel: Call Trace: > > > May 10 22:41:06 oscar kernel: [__slab_error+30/32] __slab_error+0x1e/0x20 > > > May 10 22:41:06 oscar kernel: [check_poison_obj+376/384] > > > check_poison_obj+0x178/0x180 May 10 22:41:06 oscar kernel: > > > [kmalloc+221/392] kmalloc+0xdd/0x188 May 10 22:41:06 oscar kernel: > > > [alloc_skb+64/240] alloc_skb+0x40/0xf0 May 10 22:41:06 oscar kernel: > > Yeah, more bugs in the NAT netfilter changes. Debugging this one > patch is becomming a full time job :-( > > This should fix it. Rusty, you're computing checksums and mangling > src/dst using header pointers potentially pointing to free'd skbs. > Did you mean to send a one megabyte diff? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Slab corruption mm3 + davem fixes 2003-05-11 22:15 ` Andrew Morton @ 2003-05-11 21:24 ` David S. Miller 2003-05-11 22:34 ` David S. Miller 1 sibling, 0 replies; 6+ messages in thread From: David S. Miller @ 2003-05-11 21:24 UTC (permalink / raw) To: akpm; +Cc: tomlins, linux-mm, linux-kernel, rusty, laforge From: Andrew Morton <akpm@digeo.com> Date: Sun, 11 May 2003 15:15:06 -0700 Did you mean to send a one megabyte diff? Fuck wrong patch, that one was a 2.4.x backport of IPSEC enjoy :-) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Slab corruption mm3 + davem fixes 2003-05-11 22:15 ` Andrew Morton 2003-05-11 21:24 ` David S. Miller @ 2003-05-11 22:34 ` David S. Miller 2003-05-12 7:44 ` Ed Tomlinson 1 sibling, 1 reply; 6+ messages in thread From: David S. Miller @ 2003-05-11 22:34 UTC (permalink / raw) To: Andrew Morton; +Cc: tomlins, linux-mm, linux-kernel, rusty, laforge [-- Attachment #1: Type: text/plain, Size: 1237 bytes --] On Sun, 2003-05-11 at 15:15, Andrew Morton wrote: > "David S. Miller" <davem@redhat.com> wrote: > > > > On Sun, 2003-05-11 at 09:21, Ed Tomlinson wrote: > > > I am also seeing this on 69-bk (as of Sunday morning) > > ... > > > On May 10, 2003 11:19 pm, Ed Tomlinson wrote: > > > > I looked at my logs and found the following error in it. My kernel is > > > > 69-mm3 with two davem fixes on it. > > ... > > > > May 10 22:41:06 oscar kernel: Call Trace: > > > > May 10 22:41:06 oscar kernel: [__slab_error+30/32] __slab_error+0x1e/0x20 > > > > May 10 22:41:06 oscar kernel: [check_poison_obj+376/384] > > > > check_poison_obj+0x178/0x180 May 10 22:41:06 oscar kernel: > > > > [kmalloc+221/392] kmalloc+0xdd/0x188 May 10 22:41:06 oscar kernel: > > > > [alloc_skb+64/240] alloc_skb+0x40/0xf0 May 10 22:41:06 oscar kernel: > > > > Yeah, more bugs in the NAT netfilter changes. Debugging this one > > patch is becomming a full time job :-( > > > > This should fix it. Rusty, you're computing checksums and mangling > > src/dst using header pointers potentially pointing to free'd skbs. > > > > Did you mean to send a one megabyte diff? Let's try this again, here is the correct patch :-) -- David S. Miller <davem@redhat.com> [-- Attachment #2: diff --] [-- Type: text/plain, Size: 4379 bytes --] # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1105 -> 1.1106 # net/ipv4/netfilter/ip_nat_core.c 1.25 -> 1.26 # net/ipv4/netfilter/ip_fw_compat_masq.c 1.8 -> 1.9 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/05/11 davem@nuts.ninka.net 1.1106 # [NETFILTER]: Fix stale skb data pointer usage in ipv4 NAT. # -------------------------------------------- # diff -Nru a/net/ipv4/netfilter/ip_fw_compat_masq.c b/net/ipv4/netfilter/ip_fw_compat_masq.c --- a/net/ipv4/netfilter/ip_fw_compat_masq.c Sun May 11 15:31:41 2003 +++ b/net/ipv4/netfilter/ip_fw_compat_masq.c Sun May 11 15:31:41 2003 @@ -35,16 +35,15 @@ unsigned int do_masquerade(struct sk_buff **pskb, const struct net_device *dev) { - struct iphdr *iph = (*pskb)->nh.iph; struct ip_nat_info *info; enum ip_conntrack_info ctinfo; struct ip_conntrack *ct; unsigned int ret; /* Sorry, only ICMP, TCP and UDP. */ - if (iph->protocol != IPPROTO_ICMP - && iph->protocol != IPPROTO_TCP - && iph->protocol != IPPROTO_UDP) + if ((*pskb)->nh.iph->protocol != IPPROTO_ICMP + && (*pskb)->nh.iph->protocol != IPPROTO_TCP + && (*pskb)->nh.iph->protocol != IPPROTO_UDP) return NF_DROP; /* Feed it to connection tracking; in fact we're in NF_IP_FORWARD, @@ -68,7 +67,7 @@ /* Setup the masquerade, if not already */ if (!info->initialized) { u_int32_t newsrc; - struct flowi fl = { .nl_u = { .ip4_u = { .daddr = iph->daddr } } }; + struct flowi fl = { .nl_u = { .ip4_u = { .daddr = (*pskb)->nh.iph->daddr } } }; struct rtable *rt; struct ip_nat_multi_range range; @@ -124,19 +123,18 @@ check_for_demasq(struct sk_buff **pskb) { struct ip_conntrack_tuple tuple; - struct iphdr *iph = (*pskb)->nh.iph; struct ip_conntrack_protocol *protocol; struct ip_conntrack_tuple_hash *h; enum ip_conntrack_info ctinfo; struct ip_conntrack *ct; int ret; - protocol = ip_ct_find_proto(iph->protocol); + protocol = ip_ct_find_proto((*pskb)->nh.iph->protocol); /* We don't feed packets to conntrack system unless we know they're part of an connection already established by an explicit masq command. */ - switch (iph->protocol) { + switch ((*pskb)->nh.iph->protocol) { case IPPROTO_ICMP: /* ICMP errors. */ ct = icmp_error_track(*pskb, &ctinfo, NF_IP_PRE_ROUTING); @@ -146,12 +144,6 @@ server here (== DNAT). Do SNAT icmp manips in POST_ROUTING handling. */ if (CTINFO2DIR(ctinfo) == IP_CT_DIR_REPLY) { - /* FIXME: Remove once NAT handled non-linear. - */ - if (skb_is_nonlinear(*pskb) - && skb_linearize(*pskb, GFP_ATOMIC) != 0) - return NF_DROP; - icmp_reply_translation(pskb, ct, NF_IP_PRE_ROUTING, CTINFO2DIR(ctinfo)); @@ -166,7 +158,7 @@ case IPPROTO_UDP: IP_NF_ASSERT(((*pskb)->nh.iph->frag_off & htons(IP_OFFSET)) == 0); - if (!get_tuple(iph, *pskb, iph->ihl*4, &tuple, protocol)) { + if (!get_tuple((*pskb)->nh.iph, *pskb, (*pskb)->nh.iph->ihl*4, &tuple, protocol)) { if (net_ratelimit()) printk("ip_fw_compat_masq: Can't get tuple\n"); return NF_ACCEPT; diff -Nru a/net/ipv4/netfilter/ip_nat_core.c b/net/ipv4/netfilter/ip_nat_core.c --- a/net/ipv4/netfilter/ip_nat_core.c Sun May 11 15:31:41 2003 +++ b/net/ipv4/netfilter/ip_nat_core.c Sun May 11 15:31:41 2003 @@ -717,10 +717,13 @@ iph = (void *)(*pskb)->data + iphdroff; /* Manipulate protcol part. */ - if (!find_nat_proto(proto)->manip_pkt(pskb, iphdroff + iph->ihl*4, + if (!find_nat_proto(proto)->manip_pkt(pskb, + iphdroff + iph->ihl*4, manip, maniptype)) return 0; + iph = (void *)(*pskb)->data + iphdroff; + if (maniptype == IP_NAT_MANIP_SRC) { iph->check = ip_nat_cheat_check(~iph->saddr, manip->ip, iph->check); @@ -952,6 +955,8 @@ READ_UNLOCK(&ip_nat_lock); hdrlen = (*pskb)->nh.iph->ihl * 4; + + inside = (void *)(*pskb)->data + (*pskb)->nh.iph->ihl*4; inside->icmp.checksum = 0; inside->icmp.checksum = csum_fold(skb_checksum(*pskb, hdrlen, ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Slab corruption mm3 + davem fixes 2003-05-11 22:34 ` David S. Miller @ 2003-05-12 7:44 ` Ed Tomlinson 2003-05-12 6:42 ` David S. Miller 0 siblings, 1 reply; 6+ messages in thread From: Ed Tomlinson @ 2003-05-12 7:44 UTC (permalink / raw) To: David S. Miller, Andrew Morton; +Cc: linux-mm, linux-kernel, rusty, laforge On May 11, 2003 06:34 pm, David S. Miller wrote: > > > Yeah, more bugs in the NAT netfilter changes. Debugging this one > > > patch is becomming a full time job :-( But you do it well... Looks like this fixes the slab problems here with 69-bk from Sunday am. > > > This should fix it. Rusty, you're computing checksums and mangling > > > src/dst using header pointers potentially pointing to free'd skbs. > > > > Did you mean to send a one megabyte diff? > > Let's try this again, here is the correct patch :-) Thanks Ed Tomlinson ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Slab corruption mm3 + davem fixes 2003-05-12 7:44 ` Ed Tomlinson @ 2003-05-12 6:42 ` David S. Miller 0 siblings, 0 replies; 6+ messages in thread From: David S. Miller @ 2003-05-12 6:42 UTC (permalink / raw) To: tomlins; +Cc: akpm, linux-mm, linux-kernel, rusty, laforge From: Ed Tomlinson <tomlins@cam.org> Date: Mon, 12 May 2003 03:44:50 -0400 On May 11, 2003 06:34 pm, David S. Miller wrote: > > > Yeah, more bugs in the NAT netfilter changes. Debugging this one > > > patch is becomming a full time job :-( But you do it well... Looks like this fixes the slab problems here with 69-bk from Sunday am. Thank you for testing. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-05-12 7:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20030511031940.97C24251B@oscar.casa.dyndns.org>
2003-05-11 16:21 ` Slab corruption mm3 + davem fixes Ed Tomlinson
[not found] ` <1052690490.4471.2.camel@rth.ninka.net>
2003-05-11 22:15 ` Andrew Morton
2003-05-11 21:24 ` David S. Miller
2003-05-11 22:34 ` David S. Miller
2003-05-12 7:44 ` Ed Tomlinson
2003-05-12 6:42 ` David S. Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox