This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cancellation and unwind


Hi.

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.

Petr

On Sun, 23 Jun 2013, Petr Salinger wrote:

Hello,

I am trying to understand how NPTL works wrt cancellation.
Please, could someone provide brief explanation here ?

So far I hit into this:

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 ...

Am I mising some obvious ?

Petr


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]