panic: ifc_free_unit: bit is already cleared
Pawel Jakub Dawidek
pjd at FreeBSD.org
Mon Oct 10 23:41:33 PDT 2005
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,
+> > +>
+> > +> I have found a repeatable panic with network device cloning, unfortunatly I am
+> > +> unable to dump on this box. This is sparc64 with a 2 day old current.
+> > The order is wrong in vlan_modevent().
+> > if_clone_detach() is freeing ifc_units field, so ifc_free_unit() should not
+> > be called after that.
+> > This patch should fix the problem:
+> > http://people.freebsd.org/~pjd/patches/if_vlan.c.patch
+> 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.
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?
Or maybe we will be able to create low-risk complete fix?
Pawel Jakub Dawidek http://www.wheel.pl
pjd at FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20051011/af5e02d0/attachment.bin
More information about the freebsd-current