On Sat, Nov 24, 2012 at 3:51 PM, Attilio Rao <[email protected]> wrote: > On Sat, Nov 24, 2012 at 3:46 PM, Ryan Stone <[email protected]> wrote: >> >> On Sat, Nov 24, 2012 at 10:01 AM, Attilio Rao <[email protected]> wrote: >>> >>> I seriously wonder why right now we don't assume the lock is unheld. >>> There are likely historically reasons for that, but I would like to >>> know which one are those and eventually fix them out. >>> FWIK, all the other locking primitives assume the lock is already >>> unheld when destroying and I think it would be good to have that for >>> mutexes as well. >>> >>> Can you please show which lock triggers the panic you saw? >>> >>> Thanks, >>> Attilio >>> >> >> It was taskqueue_free: > > taskqueue_free() must not be called in places where there are still > races, so the lock is not really meaningful and should be acquired.
Herm, I mean to say "after taskqueue_termintate() returns must not be races...". Attilio -- Peace can only be achieved by understanding - A. Einstein _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]"
