Date: Fri, 15 Sep 2006 23:24:20 +0400 From: Ruslan Ermilov <ru@freebsd.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: freebsd-current@freebsd.org Subject: Re: multicast panic in -current? Message-ID: <20060915192420.GE3291@rambler-co.ru> In-Reply-To: <17674.64156.166629.417557@grasshopper.cs.duke.edu> References: <17674.64156.166629.417557@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--C94crkcyjafcjHxo
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Sep 15, 2006 at 03:10:20PM -0400, Andrew Gallatin wrote:
>=20
> 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.
>=20
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.
:=20
: Coverity CID: 162 (incorrectly, it was re-introduced by previous commit)
> Fatal trap 12: page fault while in kernel mode
> fault virtual address =3D 0x68
> fault code =3D supervisor read, page not present
> instruction pointer =3D 0x8:0xffffffff80343402
> stack pointer =3D 0x10:0xffffffff9399b830
> frame pointer =3D 0x10:0xffffffff9399b8e0
> code segment =3D base 0x0, limit 0xfffff, type 0x1b
> =3D DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags =3D interrupt enabled, resume, IOPL =3D 0
> current process =3D 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 =3D 0x8006c0e8c, rsp =3D
> 0x7fffffffe668, rbp =3D 0x3 ---
> db>=20
>=20
> >From gdb after the reboot:
>=20
> (gdb) l *ip_output+0x352=20
> 0xffffffff80343402 is in ip_output (../../../netinet/ip_output.c:249).
> 244 }
> 245 /*
> 246 * Calculate MTU. If we have a route that is up, use tha=
t,
> 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 M=
TU
> 252 * of an interface after enabling IP on it. Beca=
use
> 253 * most netifs don't keep track of routes pointin=
g to
>=20
> 0xffffffff80337613 is in igmp_sendpkt (../../../netinet/igmp.c:510).
> 505 * XXX
> 506 * Do we have to worry about reentrancy here? Don't thin=
k so.
> 507 */
> 508 ip_output(m, router_alert, &igmprt, 0, &imo, NULL);
> 509
> 510 ++igmpstat.igps_snd_reports;
> 511 }
>=20
>=20
> Drew
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
--=20
Ruslan Ermilov
ru@FreeBSD.org
FreeBSD committer
--C94crkcyjafcjHxo
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
iD8DBQFFCv3kqRfpzJluFF4RAvT2AJ9R6PQSjmF4+WV+rJRTXWHKWzKaHQCZAdNb
WU4UErhtQ1Rh6gA01+OrOrA=
=aJr0
-----END PGP SIGNATURE-----
--C94crkcyjafcjHxo--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060915192420.GE3291>