> Yes -- isn't that the symptom you're seeing, or did I miss something? It's the mutex_oncpu in the while condition that crashes, not the on in the if condition above the do.
> It doesn't really matter since (a) only one thread ever sets the > variable, (b) there are no invariants around it, and (c) you never > dereference it. So, as soon as unp_gc decides it will use a > particular socket, it should just store the pointer to that socket in > some global unp_gc_current_socket, and when it's done (before closef), > it should set unp_gc_current_socket to null; then in soput/sofree, > just KASSERT(so != unp_gc_current_socket). But couldn't the thread that KASSERTs read a stale copy that unp_gc() nulled out but the null value didn't make it to the right CPU/cache/whatever?
