multicast panic in -current?

[Ruslan Ermilov]

On Fri, Sep 15, 2006 at 03:10:20PM -0400, Andrew Gallatin wrote:
> 
> When running sources cvsupped on Monday on amd64,
> I hit the following panic when attempting to add
> a multicast address.  I don't have a stack trace,
> but I do have a ddb trace.
> 
But today is Friday.  :-)

: RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v
: Working file: ip_output.c
: head: 1.263
: branch:
: locks: strict
: access list:
: keyword substitution: kv
: total revisions: 371;   selected revisions: 1
: description:
: ----------------------------
: revision 1.263
: date: 2006/09/11 19:56:10;  author: andre;  state: Exp;  lines: +1 -1
: Fix a NULL pointer dereference of ro->ro_rt->rt_flags by checking for the
: validity of ro->ro_rt first.  This prevents crashing on any non-normally
: routed IP packet.
: 
: Coverity CID:   162 (incorrectly, it was re-introduced by previous commit)

> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x68
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xffffffff80343402
> stack pointer           = 0x10:0xffffffff9399b830
> frame pointer           = 0x10:0xffffffff9399b8e0
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 1615 (multicast)
> [thread pid 1615 tid 100073 ]
> Stopped at      ip_output+0x352:        testb   $0x5,0x68(%rdx)
> db> tr
> Tracing pid 1615 tid 100073 td 0xffffff0013d09000
> ip_output() at ip_output+0x352
> igmp_sendpkt() at igmp_sendpkt+0x123
> igmp_joingroup() at igmp_joingroup+0xa1
> in_addmulti() at in_addmulti+0x19f
> ip_ctloutput() at ip_ctloutput+0xfc6
> sosetopt() at sosetopt+0x178
> kern_setsockopt() at kern_setsockopt+0x111
> setsockopt() at setsockopt+0x22
> syscall() at syscall+0x272
> Xfast_syscall() at Xfast_syscall+0xa8
> --- syscall (105, FreeBSD ELF64, setsockopt), rip = 0x8006c0e8c, rsp =
> 0x7fffffffe668, rbp = 0x3 ---
> db> 
> 
> >From gdb after the reboot:
> 
> (gdb) l *ip_output+0x352 
> 0xffffffff80343402 is in ip_output (../../../netinet/ip_output.c:249).
> 244             }
> 245             /*
> 246              * Calculate MTU.  If we have a route that is up, use that,
> 247              * otherwise use the interface's MTU.
> 248              */
> 249             if (ro->ro_rt->rt_flags & (RTF_UP | RTF_HOST)) {
> 250                     /*
> 251                      * This case can happen if the user changed the MTU
> 252                      * of an interface after enabling IP on it.  Because
> 253                      * most netifs don't keep track of routes pointing to
> 
> 0xffffffff80337613 is in igmp_sendpkt (../../../netinet/igmp.c:510).
> 505              * XXX
> 506              * Do we have to worry about reentrancy here?  Don't think so.
> 507              */
> 508             ip_output(m, router_alert, &igmprt, 0, &imo, NULL);
> 509
> 510             ++igmpstat.igps_snd_reports;
> 511     }
> 
> 
> Drew
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"

-- 
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20060915/19bd6a3c/attachment.pgp