[Bug nptl/15768] New: unusual paths in cancellation and unwind

["Petr.Salinger at seznam dot cz" <sourceware-bugzilla@sourceware.org>]

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.