http://defect.opensolaris.org/bz/show_bug.cgi?id=12188
--- Comment #2 from Michael Hunter <michael.hunter at sun.com> 2009-10-22 21:19:50 UTC --- (In reply to comment #1) [...] > nwamd_ncu_handle_fini_event() frees the object handle and data prior to doing > the release_and_destroy(). Problem is we drop the object lock before acquiring > the object list lock, and in this case the scan results door thread gets the > object lock before the destroy reacquires it. > > It might make sense for nwamd_object_fini() to free associated data depending > on object type. I agree. I don't think the link should be free()d and NULLd until the ref count has dropped to 0. To make this a little less racey[1] at the point you do the destroy you could mark the object as dieing and then either check that in _find() or if that is too crude check after relevant finds and immediately release and do whatever is appropriate. I can implement this fix and run it through my stress tonight tonight. [1] What I mean is you could imagine a scenario where things keep happening to this moribund object keeping its ref count above zero and on life support when it has no real value. -- Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
