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 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 NNTP newsgroup(s).