This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/14744] kill -32 $pid or kill -33 $pid on a process cancels a random thread
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sun, 12 Jan 2014 18:32:49 +0000
- Subject: [Bug nptl/14744] kill -32 $pid or kill -33 $pid on a process cancels a random thread
- Auto-submitted: auto-generated
- References: <bug-14744-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=14744
--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #2)
> Perhaps I was not clear. I (hopefully obviously) did not mean that there
> should be some global state "this application has called pthread_cancel"
> which causes any thread receiving signal 32 or 33 to get cancelled if it's
> set. The intent was that pthread_cancel should set the cancellation state on
> its target (in the TCB or thread-local storage), and a thread should never
> act upon cancellation unless this state is set.
The only sanity checking done today is:
/* Safety check. It would be possible to call this function for
other signals and send a signal from another process. This is not
correct and might even be a security problem. Try to catch as
many incorrect invocations as possible. */
if (sig != SIGCANCEL
|| si->si_pid != pid
|| si->si_code != SI_TKILL)
return;
However the implementation comment seems to indicate desiring support for
cancellation from another process?
/* We are canceled now. When canceled by another thread this flag
is already set but if the signal is directly send (internally or
from another process) is has to be done here. */
int newval = oldval | CANCELING_BITMASK | CANCELED_BITMASK;
I can't imagine under what use case you would support cancelling a thread in a
process from another process?
Comments?
--
You are receiving this mail because:
You are on the CC list for the bug.