[Bug nptl/12683] Race conditions in pthread cancellation

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=12683

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- 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
each other:

  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 [1] [2].  The rest is similar to consolidation patches I have been
working to set a C implementation plus architecture defines to set the correct
syscall usage.

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 [3] 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 [5] 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
report.

[1] https://sourceware.org/ml/libc-alpha/2016-08/msg00443.html
[2] https://sourceware.org/ml/libc-alpha/2016-08/msg00442.html
[3] https://sourceware.org/glibc/wiki/PortStatus
[4] https://lkml.org/lkml/2016/3/8/1105
[5]
https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/bz12683

-- 
You are receiving this mail because:
You are on the CC list for the bug.