Re: repeated panics in mutex_vector_enter (from unp_thread)

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

> Can you reproduce the problem with the LOCKDEBUG, DEBUG and DIAGNOSTIC
> kernel options enabled?
OK, I'll try that tomorrow.

> Do you always get the same backtrace i.e. it's always in unp_gc()?
Yes.

> Can you reproduce the problem in -current?
I didn't try. Even if it would go away, the cause may just be different timing.

What happens is that unp_gc() calls solock(), which calls 
mutex[_vector]_enter(), which temporarily enables pre-emption.
Its not clear to me what should keep another thread from calling soput() 
in the meantime, which calls mutex_obj_free(), which calls mutex_destroy() 
on the socket's lock.

One such possible race got fixed in sys/kern/uipc_socket2.c 1.117, but applying 
that fix didn't help.

At least, there should be an assertion in mutex_vector_enter() that after 
temporarily enabling pre-emption, the mutex has not been destroyed.

Also, the wording in mutex(9) "The mutex may not be used after it has been 
destroyed." doesn't state mitex_destroy() must not be called on a mutex that
someone may just be trying to mutex_enter().

Am I missing something?