Re: How to prevent a mutex being _enter()ed from being _destroy()ed?

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Fri, 10 Aug 2018 17:51:11 +0200
> From: Edgar Fuß <ef%math.uni-bonn.de@localhost>
> 
> I'm currently running an 8.0_STABLE kernel on the machine (with 6.1_STABLE 
> userland) and no panics so far. This smay be
> -- luck
> -- different timing that doesn't trigger the race
> -- a bug fixed since 6.1
> 
> If someone remembers a bug in this area fixed since 6.1, we can stop here.

I don't remember a specific bug but that is entirely plausible.  There
have been some possibly relevant changes, e.g. uipc_usrreq.c 1.175.

> What I guess is that that -16L is MUTEX_THREAD and was put there by 
> MUTEX_DESTROY(), called by mutex_destroy() called by soput() by another 
> thread that ran during the preemtion-enabled phase.
> 
> Any other ideas on how that -16L could go there?

This sounds plausible.

> Could I install some hack, that, in soput(), would panic if the socket to be
> freed is the one unp_gc() is currently working on? If that would trigger, we'd 
> get a useful traceback, no? And if that panic doesn't trigger, but the other 
> one does, we'd know that some of my assumptions were wrong.

They are unlikely to coincide like that.  More likely is that the
socket is prematurely freed before unp_gc grabs it at all.

You could do something like create a global variable that stores the
socket pointer that unp_gc is currently working on, shortly before it
tries solock, and kassert that soclose isn't given that.  But I'm not
optimistic that there's enough of a window there for you to catch
anyone in the act.