This is the mail archive of the
mailing list for the glibc project.
[Bug nptl/12683] Race conditions in pthread cancellation
- From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 12 Jan 2017 17:16:24 +0000
- Subject: [Bug nptl/12683] Race conditions in pthread cancellation
- Auto-submitted: auto-generated
- References: <email@example.com/bugzilla/>
Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:
What |Removed |Added
CC| |adhemerval.zanella at linaro dot o
--- Comment #28 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
Back to the issue reported on the bug report, I am still working on a fix for
this issue and I am currently rebasing my changes against master and checking
if there is any missing issue that I need to take care of.
I have decided to extend this fix in basically two subtasks that complement
1. Consolidate all the cancellation syscall implementations on C code to
remove the requirement of syscall-cancel.h header. This is orthogonal
to cancellation fix and aims to make the architecture adjustment simpler
(less assembly-macro code that emulates functions calls).
2. The cancellation (bz12683) fix itself which will require multiple patches
for each architecture.
For 1. I have a set of 33 patches, which 2 I already sent for review without
reply  . The rest is similar to consolidation patches I have been
working to set a C implementation plus architecture defines to set the correct
For 2. the patch is incomplete regarding architecture support. Based on current
implementation, I have added fixes for only x86, powerpc, s390, aarch64, and
arm. I summarize the steps required for each architecture fix at  and I
plan to review it after the patch rebase I am working it.
However for correct fix I am foreseeing some issues that I will need to take
care when more architectures are fixed:
1. i386 syscall code when using cancellation is suboptimal using this
cancellation mechanism due the not usage of vDSO. This has been
discussed on LKML on how kernel could help userland to accomplish
it, but afaik discussion was stalled.
2. Current code assumes maximum of 6 arguments syscalls for the
helper bridge. This is true for most architecture, however afaik
MIPS has 7 argument cancellable syscall, which will require code
adjustment. To avoid more performance issues, ideally both the
bridge function and related declaration should be arch-specific
(6 arguments if not specific, otherwise 7).
I am currently tracking some issues that have arise from code rebase and I will
check on the architectures I have access (x86, powerpc64le, arm, aarch64). For
1. I also plan to have a full make/check using all the supported architectures
and as soon I have all fixed I plan to update my sourceware branch  and
re-start discussion for 2.26.
My plan is at least to have 1. on 2.26. I will update the bugzilla with this
You are receiving this mail because:
You are on the CC list for the bug.