Re: [Qemu-devel] [RFC 08/38] rcu: init rcu_registry_lock after fork

[Alex Bennée]

Emilio G. Cota <address@hidden> 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 <address@hidden>
> ---
>  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