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, > +> > +> > +> > +> 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_at_ 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? 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 -- 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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:45 UTC