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

[Davide Cavalca]

On 2025-07-31 09:46, Florian Weimer wrote:
> * 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.  */
> 
> ?

Sure, that's definitely a better comment. Thanks!

Cheers
Davide