[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PTHREAD_MUTEX_ERRORCHECK and fork()
From: |
Christian Schoenebeck |
Subject: |
PTHREAD_MUTEX_ERRORCHECK and fork() |
Date: |
Wed, 26 Aug 2020 15:48:28 +0200 |
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
- [PATCH v5 0/1] audio/jack: fix use after free segfault, Geoffrey McRae, 2020/08/19
- [PATCH v5 1/1] audio/jack: fix use after free segfault, Geoffrey McRae, 2020/08/19
- Re: [PATCH v5 1/1] audio/jack: fix use after free segfault, Christian Schoenebeck, 2020/08/19
- Re: [PATCH v5 1/1] audio/jack: fix use after free segfault, Geoffrey McRae, 2020/08/19
- Re: [PATCH v5 1/1] audio/jack: fix use after free segfault, Gerd Hoffmann, 2020/08/20
- Re: [PATCH v5 1/1] audio/jack: fix use after free segfault, Christian Schoenebeck, 2020/08/20
- Re: [PATCH v5 1/1] audio/jack: fix use after free segfault, Paolo Bonzini, 2020/08/20
- Re: [PATCH v5 1/1] audio/jack: fix use after free segfault, Christian Schoenebeck, 2020/08/20
- Re: [PATCH v5 1/1] audio/jack: fix use after free segfault, Paolo Bonzini, 2020/08/21
- PTHREAD_MUTEX_ERRORCHECK and fork(),
Christian Schoenebeck <=
- recursive locks (in general), Christian Schoenebeck, 2020/08/21
- Re: recursive locks (in general), Paolo Bonzini, 2020/08/21
- Re: recursive locks (in general), Christian Schoenebeck, 2020/08/21
- Re: [PATCH v5 1/1] audio/jack: fix use after free segfault, Geoffrey McRae, 2020/08/21
- Re: [PATCH v5 1/1] audio/jack: fix use after free segfault, Paolo Bonzini, 2020/08/21