Emilio G. Cota <c...@braap.org> writes:
> We were unlocking this lock after fork, which is wrong since
> only the thread that holds a mutex is allowed to unlock it.
>
> Signed-off-by: Emilio G. Cota <c...@braap.org>
> ---
> util/rcu.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/util/rcu.c b/util/rcu.c
> index 8ba304d..47c2bce 100644
> --- a/util/rcu.c
> +++ b/util/rcu.c
> @@ -335,6 +335,11 @@ static void rcu_init_unlock(void)
> qemu_mutex_unlock(&rcu_registry_lock);
> qemu_mutex_unlock(&rcu_sync_lock);
> }
> +
> +static void rcu_init_child(void)
> +{
> + qemu_mutex_init(&rcu_registry_lock);
> +}
> #endif
>
> void rcu_after_fork(void)
> @@ -346,7 +351,7 @@ void rcu_after_fork(void)
> static void __attribute__((__constructor__)) rcu_init(void)
> {
> #ifdef CONFIG_POSIX
> - pthread_atfork(rcu_init_lock, rcu_init_unlock, rcu_init_unlock);
> + pthread_atfork(rcu_init_lock, rcu_init_unlock, rcu_init_child);
> #endif
Hmm previously we unlocked both rcu_sync_lock and rcu_registry_lock, is
it somehow different in it's locking rules? If I'm reading the
pthread_atfork man page right couldn't we just do:
pthread_atfork(rcu_init_lock, rcu_init_unlock, rcu_init_lock);
> rcu_init_complete();
> }
--
Alex Bennée
