This is the mail archive of the
mailing list for the glibc project.
Re: cancellation and unwind
- From: Petr Salinger <Petr dot Salinger at seznam dot cz>
- To: libc-help at sourceware dot org
- Date: Mon, 8 Jul 2013 11:02:04 +0200 (CEST)
- Subject: Re: cancellation and unwind
- References: <alpine dot LNX dot 2 dot 00 dot 1306232208270 dot 6583 at contest dot felk dot cvut dot cz>
I am resending this, as 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.
On Sun, 23 Jun 2013, Petr Salinger wrote:
I am trying to understand how NPTL works wrt cancellation.
Please, could someone provide brief explanation here ?
So far I hit into this:
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 ...
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
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 ?
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
/* 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
movl %fs:CANCELHANDLING, %eax
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 ...
Am I mising some obvious ?