malloc: Ensure that ptmalloc_init runs only once

  It is possible that multiple threads simultaneously enter
ptmalloc_init and succeed the < 0 check.  Make the comparison and
setting of __malloc_initialized atomic so that only one of them goes
through.  Additionally, if a thread sees that another thread is
running the initialization (i.e. __malloc_initialized == 0) then wait
till it is done.
---
 malloc/arena.c  | 12 +++++++++---
 malloc/malloc.c | 14 +++++++-------
 2 files changed, 16 insertions(+), 10 deletions(-)
  

* Siddhesh Poyarekar via Libc-alpha:

> It is possible that multiple threads simultaneously enter
> ptmalloc_init and succeed the < 0 check.  Make the comparison and
> setting of __malloc_initialized atomic so that only one of them goes
> through.  Additionally, if a thread sees that another thread is
> running the initialization (i.e. __malloc_initialized == 0) then wait
> till it is done.

No, this cannot happen because pthread_create calls malloc before
creating the new thread.

Thanks,
Florian
  

On 6/17/21 8:01 PM, Florian Weimer via Libc-alpha wrote:
> * Siddhesh Poyarekar via Libc-alpha:
> 
>> It is possible that multiple threads simultaneously enter
>> ptmalloc_init and succeed the < 0 check.  Make the comparison and
>> setting of __malloc_initialized atomic so that only one of them goes
>> through.  Additionally, if a thread sees that another thread is
>> running the initialization (i.e. __malloc_initialized == 0) then wait
>> till it is done.
> 
> No, this cannot happen because pthread_create calls malloc before
> creating the new thread.

Yes but I wonder if we should rely on that.  If we decide to rely on 
this semantic then we implicitly specify thread creation through methods 
other than pthread_create that happen to not call malloc as unsupported.

AFAICT it's not just a QOI issue; it may not be safe to call 
malloc_init_state twice on the same arena through different threads.

Siddhesh
  

* Siddhesh Poyarekar:

> On 6/17/21 8:01 PM, Florian Weimer via Libc-alpha wrote:
>> * Siddhesh Poyarekar via Libc-alpha:
>> 
>>> It is possible that multiple threads simultaneously enter
>>> ptmalloc_init and succeed the < 0 check.  Make the comparison and
>>> setting of __malloc_initialized atomic so that only one of them goes
>>> through.  Additionally, if a thread sees that another thread is
>>> running the initialization (i.e. __malloc_initialized == 0) then wait
>>> till it is done.
>> No, this cannot happen because pthread_create calls malloc before
>> creating the new thread.
>
> Yes but I wonder if we should rely on that.  If we decide to rely on
> this semantic then we implicitly specify thread creation through
> methods other than pthread_create that happen to not call malloc as
> unsupported.

There is no way to allocate a TCB for such foreign threads, and malloc
depends on the TCB, so this is not something that can work for
completely different reasons.

THanks,
Florian
  

On 6/18/21 11:15 AM, Florian Weimer wrote:
> There is no way to allocate a TCB for such foreign threads, and malloc
> depends on the TCB, so this is not something that can work for
> completely different reasons.

That's a fair point, thanks for reviewing this.  In that case, doesn't 
it make sense to simplify __malloc_initialized to a bool and have it set 
at ptmalloc_init entry?

Siddhesh
  

* Siddhesh Poyarekar:

> On 6/18/21 11:15 AM, Florian Weimer wrote:
>> There is no way to allocate a TCB for such foreign threads, and malloc
>> depends on the TCB, so this is not something that can work for
>> completely different reasons.
>
> That's a fair point, thanks for reviewing this.  In that case, doesn't
> it make sense to simplify __malloc_initialized to a bool and have it
> set at ptmalloc_init entry?

I think it's a three-state value to avoid calling
__malloc_initialize_hook multiple times.  This is all a bit
under-documented unfortunately.

Thanks,
Florian
  

On 6/18/21 11:25 AM, Florian Weimer wrote:
> I think it's a three-state value to avoid calling
> __malloc_initialize_hook multiple times.  This is all a bit
> under-documented unfortunately.

How so?  It's only called from ptmalloc_init now AFAICT and running 
ptmalloc_init concurrently won't work anyway.

Siddhesh
  

On 6/18/21 11:58 AM, Siddhesh Poyarekar via Libc-alpha wrote:
> On 6/18/21 11:25 AM, Florian Weimer wrote:
>> I think it's a three-state value to avoid calling
>> __malloc_initialize_hook multiple times.  This is all a bit
>> under-documented unfortunately.
> 
> How so?  It's only called from ptmalloc_init now AFAICT and running 
> ptmalloc_init concurrently won't work anyway.

To be clear what I'm suggesting is setting __malloc_initialized at the 
entry of ptmalloc_init, which should ensure that the body is executed 
only once as long as it is not called concurrently.

Siddhesh
  

* Siddhesh Poyarekar:

> On 6/18/21 11:25 AM, Florian Weimer wrote:
>> I think it's a three-state value to avoid calling
>> __malloc_initialize_hook multiple times.  This is all a bit
>> under-documented unfortunately.
>
> How so?  It's only called from ptmalloc_init now AFAICT and running
> ptmalloc_init concurrently won't work anyway.

The sequence would be something like this: application calls malloc,
ptmalloc_init is called via malloc_hook_ini, that invokes
__malloc_initialize_hook, and that calls realloc, which then calls
ptmalloc_init again via realloc_hook_ini.

But since the __malloc_initialize_hook call is the very last thing
called from ptmalloc_init, a boolean flag should be enough.

Thanks,
Florian