This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 06/21] nptl: i386: Fix Race conditions in pthread cancellation (BZ#12683)
- From: Zack Weinberg <zackw at panix dot com>
- To: libc-alpha at sourceware dot org
- Cc: adhemerval dot zanella at linaro dot org
- Date: Sun, 6 May 2018 22:49:09 -0400
- Subject: Re: [PATCH v2 06/21] nptl: i386: Fix Race conditions in pthread cancellation (BZ#12683)
- References: <20180507024909.5598-1-zackw@panix.com>
- References: <1519679016-12241-7-git-send-email-adhemerval.zanella@linaro.org>
On 26 Feb 2018, Adhemerval Zanella wrote:
> This patch adds the i386 modifications required for the BZ#12683.
> It basically provides the required ucontext_get_pc symbol, add the
> cancelable syscall wrapper and fix a thread atomic update macro.
This also seems fine.
> On i386 an arch-specific cancellation implementation is required
> because depending of the glibc configuration and underlying kernel
> the syscall may be done using a vDSO symbol (__kernel_vsyscall).
...
> Also, since glibc supports i486, the old 'int 0x80' should be used
> in the syscall wrapper. One option could make minimum default chip
> to pentium II (which implements sysenter) or add a runtime check
> on syscall_cancel.S to use 'int 0x80' or sysenter.
If I remember correctly, there can be only one 'sysenter' instruction
in the entire user address space, due to awkward limitations of the
interface it presents to the kernel. That was why __kernel_vsyscall
was added in the first place.
We can probably live with using int 0x80 for these syscalls that may
well be blocking anyway.
> Similar to x86_64, it also remove bogus arch-specific
> THREAD_ATOMIC_BIT_SET where it always reference to current thread
> instead of the one referenced by input 'descr' argument.
Same comment as for x86_64 -- shouldn't we get rid of or repair _all_ of
the THREAD_ATOMIC_ macros that don't honor their arguments?
zw