[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: kernel/2757: kernel panic in ip_forward.c
The following reply was made to PR kernel/2757; it has been noted by GNATS.
From: jolan <jolan@enteract.com>
To: <sleemburg@jvc.nl>
Cc: <gnats@openbsd.org>, <ict@jvc.nl>, GNATS Filer <gnats@cvs.openbsd.org>,
<bugs@cvs.openbsd.org>
Subject: Re: kernel/2757: kernel panic in ip_forward.c
Date: Fri, 14 Jun 2002 10:52:02 -0500 (CDT)
2.9 is no longer supported.
On Fri, 14 Jun 2002 sleemburg@jvc.nl wrote:
> >Number: 2757
> >Category: kernel
> >Synopsis: kernel panics in ip_forward every couple of hours
> >Confidential: no
> >Severity: critical
> >Priority: high
> >Responsible: bugs
> >State: open
> >Quarter:
> >Keywords:
> >Date-Required:
> >Class: sw-bug
> >Submitter-Id: net
> >Arrival-Date: Fri Jun 14 05:40:01 MDT 2002
> >Closed-Date:
> >Last-Modified:
> >Originator: Stephan Leemburg
> >Release: 2.9
> >Organization:
> JVC Nederland BV
> net
> >Environment:
>
> System : OpenBSD 2.9
> Architecture: OpenBSD.i386
> Machine : i386
> >Description:
>
> Every couple of hours, during the day, we get a kernel panic:
>
> fatal page fault in supervisor mode
> trap type 6 code 0 eip .....
> panic trap
>
> Now I build a kernel with DDB on and when it paniced again did a trace:
>
> stopped at ip_forward+0x1a1: movl 0x4(%eax), %eax
>
> _ip_forward(e0f8d100, 0, 0, e0101d70, e0f8d100) at _ip_forward+0x1a1
> _ipv_input(e0f8d100, 0, 0, 0) at _ipv4_input+0x38e
> _ipintr(f9510010, e02d0010, e02d1c70, e0101d3e, f9512ce4) at _ipintr+0x9c
>
> bad frame pointer 0xf9512c7c
>
> The same trace appears at every crash. This machine is used as a firewall,
> with the following interfaces:
>
>
> lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 32972
> inet 127.0.0.1 netmask 0xff000000
> lo1: flags=8008<LOOPBACK,MULTICAST> mtu 32972
> de0: flags=8963<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
> media: Ethernet autoselect (100baseTX full-duplex)
> status: active
> inet 172.17.1.7 netmask 0xffff0000 broadcast 172.17.255.255
> de1: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> media: Ethernet autoselect (10baseT)
> status: active
> inet 10.200.25.249 netmask 0xffffff00 broadcast 10.200.25.255
> de2: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> media: Ethernet autoselect (10baseT)
> status: active
> de3: flags=8963<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
> media: Ethernet autoselect (10baseT)
> status: active
> tun0: flags=51<UP,POINTOPOINT,RUNNING> mtu 3000
> inet 204.90.246.2 --> 204.90.246.3 netmask 0xffffff00
> tun1: flags=10<POINTOPOINT> mtu 3000
> enc0: flags=0<> mtu 1536
> bridge0: flags=41<UP,RUNNING> mtu 1500
> bridge1: flags=0<> mtu 1500
> gre0: flags=8010<POINTOPOINT,MULTICAST> mtu 1450
>
> It bridges between interface d0 (which is numbered) and d3 (which is unnumbered)
>
> We always have seen many:
>
> rtfree: 0xe0fd6600 not freed (neg refs)
>
> errors but since monday they appeared more and more, probably due to changed
> network activity on a RAS attached on de3 or due to more RIP traffic on de0.
>
> I get the feeling that these messages are related to the panic's as they
> both involve rt.
>
> I checked with objdump and think that the problem is within the following
> ip_forward() code accessing rt info which has been released by other code:
>
>
> /*
> * If forwarding packet using same interface that it came in on,
> * perhaps should send a redirect to sender to shortcut a hop.
> * Only send redirect if source is sending directly to us,
> * and if packet was not source routed (or has any options).
> * Also, don't send redirect if forwarding using a default route
> * or a route modified by a redirect.
> * Don't send redirect if we advertise destination's arp address
> * as ours (proxy arp).
> */
> if (rt->rt_ifp == m->m_pkthdr.rcvif &&
> (rt->rt_flags & (RTF_DYNAMIC|RTF_MODIFIED)) == 0 &&
> THIS LINE---> satosin(rt_key(rt))->sin_addr.s_addr != 0 &&
> ipsendredirects && !srcrt &&
> !ip_weadvertise(satosin(rt_key(rt))->sin_addr.s_addr)) {
> if (rt->rt_ifa &&
> (ip->ip_src.s_addr & ifatoia(rt->rt_ifa)->ia_subnetmask) ==
> ifatoia(rt->rt_ifa)->ia_subnet) {
> if (rt->rt_flags & RTF_GATEWAY)
> dest = satosin(rt->rt_gateway)->sin_addr.s_addr;
> else
> dest = ip->ip_dst.s_addr;
>
> because of:
>
> e01fc560 <_ip_forward>:
> e01fc560: 55 push %ebp
> e01fc561: 89 e5 mov %esp,%ebp
> e01fc563: 83 ec 1c sub $0x1c,%esp
> (...)
> e01fc6c1: 89 c7 mov %eax,%edi
> e01fc6c3: 83 c4 10 add $0x10,%esp
> e01fc6c6: 85 ff test %edi,%edi
> e01fc6c8: 74 1b je e01fc6e5 <_ip_forward+0x185>
> e01fc6ca: 83 c4 f8 add $0xfffffff8,%esp
> e01fc6cd: 8a 06 mov (%esi),%al
> e01fc6cf: 24 0f and $0xf,%al
> e01fc6d1: 25 ff 00 00 00 and $0xff,%eax
> e01fc6d6: c1 e0 02 shl $0x2,%eax
> e01fc6d9: 50 push %eax
> e01fc6da: 57 push %edi
> e01fc6db: e8 e4 5c fb ff call e01b23c4 <_m_pullup>
> e01fc6e0: 89 c7 mov %eax,%edi
> e01fc6e2: 83 c4 10 add $0x10,%esp
> e01fc6e5: 8b 55 08 mov 0x8(%ebp),%edx
> e01fc6e8: 8b 42 14 mov 0x14(%edx),%eax
> e01fc6eb: 39 43 40 cmp %eax,0x40(%ebx)
> e01fc6ee: 0f 85 8f 00 00 00 jne e01fc783 <_ip_forward+0x223>
> e01fc6f4: f6 43 34 30 testb $0x30,0x34(%ebx)
> e01fc6f8: 0f 85 85 00 00 00 jne e01fc783 <_ip_forward+0x223>
> e01fc6fe: 8b 43 0c mov 0xc(%ebx),%eax
> --> e01fc701: 8b 40 04 mov 0x4(%eax),%eax
>
>
>
>
> >How-To-Repeat:
>
> The problem appears several times a day, we are still investigating
> the exact allignment of events that trigger this.
>
> >Fix:
> We are not aware of any fix and after having investigated the 3.1
> srcsys tree, I could not detect any apparent fixes that would have
> been applied to fix this problem.
>
> We are prepared to provide more information if needed.
>
> >Release-Note:
> >Audit-Trail:
> >Unformatted: