Re: panic: ifc_free_unit: bit is already cleared

From: Andrew Thompson <thompsa_at_freebsd.org>
Date: Tue, 11 Oct 2005 09:35:26 +1300
On Mon, Oct 10, 2005 at 01:29:00PM -0700, Brooks Davis wrote:
> On Mon, Oct 10, 2005 at 03:22:08PM +1300, Andrew Thompson wrote:
> > On Mon, Oct 10, 2005 at 03:28:49AM +0400, Yar Tikhiy wrote:
> > > On Thu, Oct 06, 2005 at 10:09:50AM +1300, Andrew Thompson wrote:
> > > 
> > > FWIW, I tried to look at the $subject problem since I had had it
> > > before, but just got a different panic:
> > > 
> > >         Memory modified after free 0xc140b000(4092) val=deadc0dc _at_ 0xc140b000
> > >         panic: Most recently used by clone
> > > 
> > > The clone code seems to have decremented something (refcount?) twice
> > > after freeing the memory chunk.
> > 
> > I have been testing this patch and I think it fixes all the problems
> > discussed.
> > 
> > It changes refcounting to count the number of cloned interfaces so
> > ifc_units is only freed when its safe. A new function has been added to
> > decrement this when a simple cloner module is unloaded. The cloner is
> > still detached first to prevent the race.
> > 
> > In most cases the change is as simple as:
> >                 while ((sc = LIST_FIRST(&gre_softc_list)) != NULL) {
> >                         LIST_REMOVE(sc, sc_list);
> >                         mtx_unlock(&gre_mtx);
> > +                       ifc_simple_free(&gre_cloner, GRE2IFP(sc));
> >                         gre_destroy(sc);
> >                         mtx_lock(&gre_mtx);
> >                 }
> 
> I don't see any reason why you can't just replace the specific destroy
> calls with calls to ifc_simple_destroy().  That would avoid expanding
> the API.
 
I did experiment with that. On some interfaces it would cause the global
mutex to be recursed, but that can be fixed. I'll have another go.


Andrew
Received on Mon Oct 10 2005 - 18:35:29 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:45 UTC