Date: Tue, 11 Oct 2005 09:07:15 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: Brooks Davis <brooks@FreeBSD.org>, FreeBSD Current <current@FreeBSD.org>, Andrew Thompson <thompsa@FreeBSD.org> Subject: Re: panic: ifc_free_unit: bit is already cleared Message-ID: <20051011160715.GA2264@odin.ac.hmc.edu> In-Reply-To: <20051011064014.GA76710@garage.freebsd.pl> References: <20051005024903.GA72743@heff.fud.org.nz> <20051005203639.GA20552@garage.freebsd.pl> <20051005205515.GA30350@odin.ac.hmc.edu> <20051011064014.GA76710@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
--7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 11, 2005 at 08:41:16AM +0200, Pawel Jakub Dawidek wrote: > On Wed, Oct 05, 2005 at 01:55:15PM -0700, Brooks Davis wrote: > +> On Wed, Oct 05, 2005 at 10:36:39PM +0200, Pawel Jakub Dawidek wrote: > +> > On Wed, Oct 05, 2005 at 03:49:03PM +1300, Andrew Thompson wrote: > +> > +> Hi, > +> > +>=20 > +> > +> I have found a repeatable panic with network device cloning, unfo= rtunatly I am > +> > +> unable to dump on this box. This is sparc64 with a 2 day old curr= ent. > +> >=20 > +> > The order is wrong in vlan_modevent(). > +> >=20 > +> > if_clone_detach() is freeing ifc_units field, so ifc_free_unit() sho= uld not > +> > be called after that. > +> >=20 > +> > This patch should fix the problem: > +> >=20 > +> > http://people.freebsd.org/~pjd/patches/if_vlan.c.patch > +>=20 > +> Yes. This does introduce a race in that a new interface could > +> be created between the vlan_clone_destroy loop and the call to > +> if_clone_detach. It's going to be hard to trigger, but it probably > +> should be fixed. Since cloning isn't performance critical, I think > +> adding a dead flag to the clone structure and failing all attempts once > +> the flag is set. >=20 > I think it is a low-risk patch and the race isn't really critical. > What do you guys think about going with this fix for 6.0? > I'm all for better fix (the one thompsa@ is working on) going to HEAD > and 6.1, but better fix - higher risk. > So what's your opinion? >=20 > Or maybe we will be able to create low-risk complete fix? The race is mostly a non-issue so I'd be OK with the low-risk fix. To hit the race you'd have to be trying (or forget that you are running some sort of interface management daemon). -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDS+MyXY6L6fI4GtQRAvY4AKCSq9kBz4+X42rna8XNSUvg/oXokACghTDP yqIVOFyo0fCnytwAu9/FaZ8= =NFiy -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051011160715.GA2264>