From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andreas Schwab <schwab@suse.de>
Cc: mtk.manpages@gmail.com, David Miller <davem@davemloft.net>,
libc-alpha@sourceware.org,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
linux-man@vger.kernel.org, Roland McGrath <roland@hack.frob.com>
Subject: Re: Race and segmentation fault in pthread_kill() vs thread teardown
Date: Sun, 29 Dec 2013 02:11:34 +1300 [thread overview]
Message-ID: <52BECE06.30001@gmail.com> (raw)
In-Reply-To: <1497173819.27140.1380715480773.JavaMail.zimbra@efficios.com>
On 10/03/13 01:04, Mathieu Desnoyers wrote:
> ----- Original Message -----
>> From: "Andreas Schwab" <schwab@suse.de>
>> To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
>> Cc: "David Miller" <davem@davemloft.net>, libc-alpha@sourceware.org, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
>> Sent: Wednesday, October 2, 2013 4:11:23 AM
>> Subject: Re: Race and segmentation fault in pthread_kill() vs thread teardown
>>
>> The POSIX spec is pretty clear:
>>
>> If an application attempts to use a thread ID whose lifetime has ended,
>> the behavior is undefined.
>>
>> I'd suggest to file a bug report with the Austin group wrt to the
>> wording in pthread_kill.
>
> CCing man pages maintainers,
>
> Interestingly enough, the specification has been updated:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_kill.html
>
> to remove the ESRCH return value in
>
> Issue 7
> Austin Group Interpretation 1003.1-2001 #142 is applied, removing the [ESRCH] error condition.
>
> It looks like a discrepancy between the spec and the man page that causes this confusion. We might want to update pthread_kill(3), keeping ESRCH documented, but clearly marked as deprecated, and clarify that calling pthread_kill() on a non-existing thread is undefined.
>
> We should probably remove this part entirely:
>
> " but error checking is still per‐
> formed; this can be used to check for the existence of a thread ID."
>
> Thoughts ?
Mathieu, et al.
I applied the patch below. Look okay to you?
Cheers,
Michael
diff --git a/man3/pthread_kill.3 b/man3/pthread_kill.3
index 674168f..bbf5573 100644
--- a/man3/pthread_kill.3
+++ b/man3/pthread_kill.3
@@ -47,8 +47,7 @@ The signal is asynchronously directed to
If
.I sig
-is 0, then no signal is sent, but error checking is still performed;
-this can be used to check for the existence of a thread ID.
+is 0, then no signal is sent, but error checking is still performed.
.SH RETURN VALUE
On success,
.BR pthread_kill ()
@@ -58,13 +57,8 @@ on error, it returns an error number, and no signal is sent.
.TP
.B EINVAL
An invalid signal was specified.
-.TP
-.B ESRCH
-No thread with the ID
-.I thread
-could be found.
.SH CONFORMING TO
-POSIX.1-2001.
+POSIX.1-2008.
.SH NOTES
Signal dispositions are process-wide:
if a signal handler is installed,
@@ -72,6 +66,19 @@ the handler will be invoked in the thread
.IR thread ,
but if the disposition of the signal is "stop", "continue", or "terminate",
this action will affect the whole process.
+
+POSIX.1-2008 recommends that if an implementation detects the use
+of a thread ID after the end of its lifetime,
+.BR pthread_kill ()
+should return the error
+.BR ESRCH .
+The glibc implementation returns this error in the cases where
+an invalid thread ID can be detected.
+But note also that POSIX says that an attempt to use a thread ID whose
+lifetime has ended produces undefined behavior,
+and an attempt to use an invalid thread ID in a call to
+.BR pthread_kill ()
+can, for example, cause a segmentation fault.
.SH SEE ALSO
.BR kill (2),
.BR sigaction (2),
prev parent reply other threads:[~2013-12-28 13:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <305581948.26980.1380684877897.JavaMail.zimbra@efficios.com>
[not found] ` <675415986.27031.1380686764309.JavaMail.zimbra@efficios.com>
[not found] ` <mvm8uyc2itw.fsf@hawking.suse.de>
2013-10-02 12:04 ` Race and segmentation fault in pthread_kill() vs thread teardown Mathieu Desnoyers
2013-10-02 18:05 ` Roland McGrath
2013-12-28 13:11 ` Michael Kerrisk (man-pages) [this message]
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=52BECE06.30001@gmail.com \
--to=mtk.manpages@gmail.com \
--cc=davem@davemloft.net \
--cc=libc-alpha@sourceware.org \
--cc=linux-man@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=roland@hack.frob.com \
--cc=schwab@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.