PTHREAD_MUTEX_ERRORCHECK and fork()

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Freitag, 21. August 2020 15:13:35 CEST Paolo Bonzini wrote:
> On 20/08/20 14:00, Christian Schoenebeck wrote:
> > One way would be a recursive type and logging a warning, which you
> > obviously don't like; another option would be an assertion fault instead
> > to make developers immediately aware about the double lock on early
> > testing. Because on a large scale project like this, it is almost
> > impossible for all developers to be aware about all implied locks. Don't
> > you think so?
> > 
> > At least IMO the worst case would be a double unlock on a non-recursive
> > main thread mutex and running silently into undefined behaviour.
> 
> Yes, more assertions are always fine.
> 
> We were using errorcheck mutexes until a few years ago, unfortunately we
> couldn't because they are broken with respect to fork (commit 24fa90499,
> "qemu-thread: do not use PTHREAD_MUTEX_ERRORCHECK", 2015-03-05).

I had a go on this one; you still get EPERM when trying to 
pthread_mutex_unlock() from a forked child process on a 
PTHREAD_MUTEX_ERRORCHECK mutex locked by parent process.

The common opinion though seems to be that unlocking parent's lock(s) by child 
process was illegal:
https://groups.google.com/forum/#!topic/comp.programming.threads/ywMInaZjmqo
https://sourceware.org/bugzilla/show_bug.cgi?id=2745

The relevant section from POSIX:

	fork - create a new process
	...
	A process shall be created with a single thread. If a multi-threaded 
	process calls fork(), the new process shall contain a replica of the 
	calling thread and its entire address space, possibly including the states 
	of mutexes and other resources. Consequently, to avoid errors, the child 
	process may only execute async-signal-safe operations until such time as 
	one of the exec functions is called.

https://pubs.opengroup.org/onlinepubs/9699919799/

Best regards,
Christian Schoenebeck