[PATCH 0/2] tests: Don't destroy locked mutexes

[Daniel P. Berrangé]

On Mon, Feb 14, 2022 at 02:32:55PM +0100, Michal Privoznik wrote:
> I've rewritten our virMutexes to check for failures [1] and saw couple
> of problems. In most cases we are destroying a locked mutex which these
> patches aim to fix. Then we have virLogLock() which is locked in
> virFork() and then unlocked from child (a different process) which is
> problematic. Pthread doesn't like it when one thread locks a mutex only
> so that another one unlocks it. Semaphores don't care.

Despite behaviuor being undefined, in practice it works with any
impl we have in supported platforms.

The key problem we're addressing is that the child process needs
to inherit a known state for the mutex. Whether that state is
locked or unlocked doesn't matter, as long as it has a bulletproof
guarantee of what that status is.

We call virLogLock before fork() to guarantee a locked state,
by blocking on any other threads in the parent that might be
temporarily holding it.

The pthread_atfork() handler can be used todo the same trick
if you don't control the place where fork() is called. The
man page explicitly says

  https://linux.die.net/man/3/pthread_atfork

   "The expected usage is that the prepare handler acquires
    all mutex locks and the other two fork handlers release
    them."

I understand why error checking mutexes reject this but AFAIK
what we do is the only possible solution that exists, other
than never touching any mutexes at all in the child which is
not viable for us.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|