[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Jan 2020 15:46:56 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Cc: Simon <simonhf@...il.com>
Subject: Re: Bug report: Reproduction of seg fault caused by musl
thread creation race condition
On Mon, Jan 27, 2020 at 09:37:59PM +0100, Szabolcs Nagy wrote:
> * Simon <simonhf@...il.com> [2020-01-27 11:59:24 -0800]:
> > > Upon successful completion, pthread_create() shall store the ID
> > >
> >
> > "Upon successfully completion" is somewhat vague wording IMO which could
> > result in misinterpretation? You seem to have interpreted it as "Upon
> > function completion", but surely if clone() succeeds, and the new thread
> > starts running, then there is already "successful completion" even before
> > pthread_create() has returned to caller?
>
> there is no ambiguity here.
>
> completion of a function call, such as pthread_create,
> is well defined and it's the point that's sequenced
> after the call returns, you have to synchronize with
> that point to read the value from another thread.
>
> > This seems more specific than "Upon successful completion" but still
> > doesn't exactly tie down whether the thread ID should be written before the
>
> the point is to not tie the behaviour down so you cannot
> rely on it, this allows implementation freedom.
I don't think this particular case of implementation freedom matters a
lot to musl, but applications should still respect it because it may
matter to implementations where more of thread creation is handled by
the kernel and the thread id (in the pthread_t sense) really doesn't
exist until the syscall returns.
I see some good reasons for and against changing it but would probably
lean towards leaving it alone as the "default course of action" --
mainly in case there are reasons against that aren't immediately
apparent to us right now..
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
