Re: Status of cancellation fixed (eg, BZ 12683)

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

I am currently rebasing my patches 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

On 11/01/2017 09:25, Torvald Riegel wrote:
> Adhemerval,
> 
> could you summarize the state of your cancellation fixes?  Are there any
> fixes that still need review?  It seems SYSCALL_CANCEL is still using
> the old style of enabling/disabling cancellation -- what is missing for
> this to use the new approach?
> Also, futex-internal still uses the old approach too instead of
> SYSCALL_CANCEL; should this be changed to use SYSCALL_CANCEL?
> 
> Perhaps updating 12683 with a summary would be helpful for users too.
>