stdlib: resolve a double lock init issue after fork [BZ #32994]

[Florian Weimer]

* Davide Cavalca:

> From 6021819e5b528f93fb325ddd9d59f69a39b0a162 Mon Sep 17 00:00:00 2001
> From: Davide Cavalca <davide@cavalca.name>
> Date: Sat, 14 Jun 2025 11:31:17 +0200
> Subject: [PATCH] stdlib: resolve a double lock init issue after fork [BZ
>  #32994]
>
> The __abort_fork_reset_child (introduced in
> d40ac01cbbc66e6d9dbd8e3485605c63b2178251) call resets the lock after the
> fork. This causes a DRD regression in valgrind
> (https://bugs.kde.org/show_bug.cgi?id=503668), as it's effectively a
> double initialization, despite it being actually ok in this case. As
> suggested in https://sourceware.org/bugzilla/show_bug.cgi?id=32994#c2
> we replace it here with a memcpy of another initialized lock instead,
> which makes valgrind happy.
>
> v2: move the lock definition into __abort_fork_reset_child
> v3: style fixes
> v4: more style fixes, add missing include for Hurd
>
> Signed-off-by: Davide Cavalca <davide@cavalca.name>
> ---
>  stdlib/abort.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/stdlib/abort.c b/stdlib/abort.c
> index caa9e6dc04..1dabaa3ba6 100644
> --- a/stdlib/abort.c
> +++ b/stdlib/abort.c
> @@ -19,6 +19,7 @@
>  #include <internal-signals.h>
>  #include <libc-lock.h>
>  #include <pthreadP.h>
> +#include <string.h>
>  #include <unistd.h>
>  
>  /* Try to get a machine dependent instruction which will make the
> @@ -42,7 +43,9 @@ __libc_rwlock_define_initialized (static, lock);
>  void
>  __abort_fork_reset_child (void)
>  {
> -  __libc_rwlock_init (lock);
> +  /* The reset_lock is copied into lock after the fork */
> +  __libc_rwlock_define_initialized (, reset_lock);
> +  memcpy (&lock, &reset_lock, sizeof (lock));
>  }

Is it okay if I turn the comment into:

  /* Reinitialize lock without calling pthread_rwlock_init, to
     avoid a valgrind DRD false positive.  */

?

Thanks,
Florian