public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug nptl/15768] New: unusual paths in cancellation and unwind
@ 2013-07-22 8:02 Petr.Salinger at seznam dot cz
2014-06-13 13:19 ` [Bug nptl/15768] " fweimer at redhat dot com
2014-06-13 13:20 ` fweimer at redhat dot com
0 siblings, 2 replies; 3+ messages in thread
From: Petr.Salinger at seznam dot cz @ 2013-07-22 8:02 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15768
Bug ID: 15768
Summary: unusual paths in cancellation and unwind
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: nptl
Assignee: unassigned at sourceware dot org
Reporter: Petr.Salinger at seznam dot cz
CC: drepper.fsp at gmail dot com
Hi.
I asked for some clarification of cancellation and unwind in
http://sourceware.org/ml/libc-help/2013-06/msg00055.html
I got no answer.
I belive that "a)" - kill with only 1 argument -
and "c)" - no setup of rdx - are bugs.
But I am not sure, as cancellation might be too tricky.
Petr
--------------------------------------------------------------------
a)
nptl/forward.c
FORWARD_NORETURN(__pthread_unwind,
...
INTERNAL_SYSCALL_DECL (err);
INTERNAL_SYSCALL (kill, err, 1, SIGKILL);
But usually "int kill(pid_t pid, int sig)" holds.
It looks like pid 9 is killed by random signal ...
b)
nptl/cancellation.c: __pthread_disable_asynccancel (int oldtype)
/* We cannot return when we are being canceled. Upon return the
thread might be things which would have to be undone. The
following loop should loop until the cancellation signal is
delivered. */
while (__builtin_expect ((newval & (CANCELING_BITMASK | CANCELED_BITMASK))
== CANCELING_BITMASK, 0))
{
lll_futex_wait (&self->cancelhandling, newval, LLL_PRIVATE);
newval = THREAD_GETMEM (self, cancelhandling);
}
Can this ever return, or will it only again and again call kernel,
until thread is somehow terminated ?
c)
nptl x86_64 specific cancellation.S
The comment says:
/* It is crucial that the functions in this file don't modify registers
other than %rax and %r11. The syscall wrapper code depends on this
because it doesn't explicitly save the other registers which hold
relevant values. */
But later on:
3: andl $(TCB_CANCELING_BITMASK|TCB_CANCELED_BITMASK), %eax
cmpl $TCB_CANCELING_BITMASK, %eax
je 4f
1: ret
/* Performance doesn't matter in this loop. We will
delay until the thread is canceled. And we will unlikely
enter the loop twice. */
4: mov %fs:0, %RDI_LP
movl $__NR_futex, %eax
xorq %r10, %r10
addq $CANCELHANDLING, %rdi
LOAD_PRIVATE_FUTEX_WAIT (%esi)
syscall
movl %fs:CANCELHANDLING, %eax
jmp 3b
Again, can this ever return ?
Or the modification of registers is not problem any more ?
And moreover, the third agument of futex (rdx, old value) is not set before
syscall at all ...
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-06-13 13:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-22 8:02 [Bug nptl/15768] New: unusual paths in cancellation and unwind Petr.Salinger at seznam dot cz
2014-06-13 13:19 ` [Bug nptl/15768] " fweimer at redhat dot com
2014-06-13 13:20 ` fweimer at redhat dot com
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).