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

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

I pushed a rebased version on my bz12683 branch [1].  It is quite a long patchset,
but it is at least somewhat complete:

  - It removes all the cancellable syscall generation from syscalls.list and
    implement them in C.  It simplifies each architecture adjustment by a huge
    amount and also for new ports.

  - I added a generic C version for the bridge cancellable entrypoint that
    should work in varios ABIs.  It really depends on how the architecture 
    implements INTERNAL_SYSCALL_NCS, since the ending mark should be the
    next instruction after the syscalls or what kernel points for a cancelled
    syscall with side-effects.  It works on x86_64, aarch64, and mips64 at
    least.

  - All supported architecture builds correctly, although for some I can't
    really tell if it actually runs correctly.

This version still uses the old synchronization mechanism for the cancel
signaling and handling.  My plan is to review and try to adjust to our
C11 memory model, which can potentially simplify the code, and I can use
some help on this ;).

[1] https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/bz12683

On 11/01/2017 16:05, Adhemerval Zanella wrote:
> 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.
>>