Date: Sat, 11 Feb 2006 17:00:23 GMT From: David Malone <dwmalone@maths.tcd.ie> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/93170 : Changing system date causes panic in nd6_timer Message-ID: <200602111700.k1BH0NBs095385@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/93170; it has been noted by GNATS.
From: David Malone <dwmalone@maths.tcd.ie>
To: bug-followup@FreeBSD.org, kris@FreeBSD.org
Cc: rwatson@FreeBSD.org, iedowse@maths.tcd.ie, dwmalone@maths.tcd.ie
Subject: Re: kern/93170 : Changing system date causes panic in nd6_timer
Date: Sat, 11 Feb 2006 16:59:38 +0000
I'm fairly sure I know what's going on here, as I've seen a few
more of these panics. There seems to be a bundle of IPv6 neighbour
discovery code that uses splnet() and hasn't had any locking added
to it yet. One of these bits of code is walking some global lists
and is obviously getting into trouble.
I believe this same code is also causing dirhash panics people have
reported 'cos some of the memory it is using is getting reused by
dirhash.
I sent the message below to Robert a while ago - since I haven't
heard back from him, I'm going to have a go at adding some locking.
David.
Subject: IPv6 address list locking.
Date: Fri, 20 Jan 2006 17:48:57 +0000
From: David Malone <dwmalone@maths.tcd.ie>
Message-ID: <200601201748.aa69772@salmon.maths.tcd.ie>
Hi Robert,
I've been trying to trace some use-after-free problems that have
paniced the kernel in dirhash. A few weeks ago I got a panic that
indicated that the ifnet malloc pool might be the problem. Using
memguard on my desktop in Dublin paniced today and, judging by the
reports of the guy who reset it for me, it paniced at nd6_timer+0xe8.
This looks like a bit of nd6_timer code that accesses a global list
of IPv6 addresses stored in a variable called in6_ifaddr. Rather
annoyingly this variable has the same name as a structure, so it
is difficult to grep for. However, I don't see any locking of
accesses to this variable.
Do you have a scheme for locking globals like this in the IPv6
stack? Does it look like nd6_timeout is violaing this locking?
David.
in6.c: for (ia = in6_ifaddr; ia; ia = ia->ia_next) {
in6.c: for (ia = in6_ifaddr; ia; ia = ia->ia_next) {
in6.c: for (ia = in6_ifaddr; ia; ia = ia->ia_next) {
in6_src.c: for (ia = in6_ifaddr; ia; ia = ia->ia_next) {
nd6.c: for (ia6 = in6_ifaddr; ia6; ia6 = nia6) {
nd6.c: for (ia = in6_ifaddr; ia; ia = ia_next) {
nd6_rtr.c: for (ifa = in6_ifaddr; ifa; ifa = ifa->ia_next) {
nd6_rtr.c: for (ifa = in6_ifaddr; ifa; ifa = ifa->ia_next) {
nd6_rtr.c: for (ifa = in6_ifaddr; ifa; ifa = ifa->ia_next) {
nd6_rtr.c: for (ia = in6_ifaddr; ia; ia = ia->ia_next) {
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200602111700.k1BH0NBs095385>