From: Florian Weimer <fweimer@redhat.com>
To: Siddhesh Poyarekar <siddhesh@sourceware.org>
Cc: Siddhesh Poyarekar via Libc-alpha <libc-alpha@sourceware.org>
Subject: Re: [PATCH] malloc: Ensure that ptmalloc_init runs only once
Date: Fri, 18 Jun 2021 07:45:50 +0200 [thread overview]
Message-ID: <87y2b7u3n5.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <68f4386f-9ae5-8791-31bf-7dcf14479847@sourceware.org> (Siddhesh Poyarekar's message of "Fri, 18 Jun 2021 08:01:30 +0530")
* 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
next prev parent reply other threads:[~2021-06-18 5:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-17 10:32 Siddhesh Poyarekar
2021-06-17 14:31 ` Florian Weimer
2021-06-18 2:31 ` Siddhesh Poyarekar
2021-06-18 5:45 ` Florian Weimer [this message]
2021-06-18 5:51 ` Siddhesh Poyarekar
2021-06-18 5:55 ` Florian Weimer
2021-06-18 6:28 ` Siddhesh Poyarekar
2021-06-18 6:32 ` Siddhesh Poyarekar
2021-06-18 6:36 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y2b7u3n5.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=siddhesh@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).