x86_64 was just plain wrong in the cancel-flag-already-set path, and
crashing.
the more subtle error was not clearing the saved stack pointer before
returning to c code. this could result in the signal handler
misidentifying c code as the pre-syscall part of the asm, and acting
on cancellation at the wrong time, and thus resource leak race
conditions.
also, now __cancel (in the c code) is responsible for clearing the
saved sp in the already-cancelled branch. this means we have to use
call rather than jmp to ensure the stack pointer in the c will never
match what the asm saved.
void __cancel()
{
pthread_t self = __pthread_self();
+ self->cp_sp = 0;
self->canceldisable = 1;
self->cancelasync = 0;
pthread_exit(PTHREAD_CANCELED);
self->cp_sp = 0;
self->cp_ip = 0;
r = __syscall_cp_asm(&self->cp_sp, nr, u, v, w, x, y, z);
- self->cp_sp = old_sp;
self->cp_ip = old_ip;
+ self->cp_sp = old_sp;
if (r == -EINTR && self->cancel) __cancel();
return r;
}
popl %edi
popl %esi
popl %ebx
+ xorl %edx,%edx
+ movl 4(%esp),%ecx
+ movl %edx,(%ecx)
ret
-2: xorl %eax,%eax
- movl %eax,4(%ecx)
- movl %eax,(%ecx)
- pushl $-1
- call __cancel
+2: call __cancel
mov 16(%rdi),%eax
test %eax,%eax
jnz 2f
+ mov %rdi,%r11
mov %rsi,%rax
mov %rdx,%rdi
mov %rcx,%rsi
mov %r9,%r10
mov 8(%rsp),%r8
mov 16(%rsp),%r9
+ mov %r11,8(%rsp)
1: syscall
+ xor %ecx,%ecx
+ mov 8(%rsp),%edi
+ mov %rcx,(%rdi)
ret
-2: xor %edi,%edi
- mov %rdi,8(%r10)
- mov %rdi,(%r10)
- dec %rdi
- jmp __cancel
+2: call __cancel