On Fri, Aug 03, 2012 at 01:33:44 +0400, Gleb Smirnoff wrote: > On Thu, Aug 02, 2012 at 04:46:42PM +0000, Bjoern A. Zeeb wrote: > B> On Thu, 2 Aug 2012, Gleb Smirnoff wrote: > B> > B> > Author: glebius > B> > Date: Thu Aug 2 13:57:49 2012 > B> > New Revision: 238990 > B> > URL: http://svn.freebsd.org/changeset/base/238990 > B> > > B> > Log: > B> > Fix races between in_lltable_prefix_free(), lla_lookup(), > B> > llentry_free() and arptimer(): > B> > > B> > o Use callout_init_rw() for lle timeout, this allows us safely > B> > disestablish them. > B> > - This allows us to simplify the arptimer() and make it > B> > race safe. > B> > o Consistently use ifp->if_afdata_lock to lock access to > B> > linked lists in the lle hashes. > B> > o Introduce new lle flag LLE_LINKED, which marks an entry that > B> > is attached to the hash. > B> > - Use LLE_LINKED to avoid double unlinking via consequent > B> > calls to llentry_free(). > B> > - Mark lle with LLE_DELETED via |= operation istead of =, > B> > so that other flags won't be lost. > B> > o Make LLE_ADDREF(), LLE_REMREF() and LLE_FREE_LOCKED() more > B> > consistent and provide more informative KASSERTs. > B> > > B> > The patch is a collaborative work of all submitters and myself. > B> > B> Quoting from 2 year old memory you just introduced a possible deadlock > B> on tbale (or with that networkstack) teardown adding the extra af_data > B> write locking to the table walk. > > Can you please give more details? I didn't get it. What else needs > afdata lock and what does it hold which is held by table walk.
Is there a deadlock in that particular change? If so, what will it take to fix it? Thanks, Ken -- Kenneth Merry k...@freebsd.org _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
