[llvm-bugs] [Bug 41856] New: CP15 barrier instructions should be emitted before the exclusives loops

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=41856

            Bug ID: 41856
           Summary: CP15 barrier instructions should be emitted before the
                    exclusives loops
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: rvojta at me.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Created attachment 21941
  --> https://bugs.llvm.org/attachment.cgi?id=21941&action=edit
Never ending loop

## Symptoms

* Rustup hangs (unable to install Rust)
  * Tracked down to parking_lot issue:
https://github.com/Amanieu/parking_lot/issues/130
* Not just Rust related, Swift has this problem as well
  *
https://forums.balena.io/t/cloud-build-fails-but-local-device-build-works-on-raspberry-pi-zero/4994

strex never succeeds and is looping indefinitely.

## Environment

* Linux kernel with CP15_BARRIER_EMULATION=y
* abi.cp15_barrier set to 1 (emulate)
* arm-unknown-linux-gnueabihf toolchain

## CP15 barrier instructions

* They're deprecated since armv7
* Linux kernel can emulate or HW exec them:
https://www.kernel.org/doc/Documentation/arm64/legacy_instructions.txt
  * abi.cp15_barrier is set to 2 (HW exec) -> there's no issue
    * The CPU must support them
    * ARMv8 in our case, which still supports them
  * abi.cp15_barrier is set to 1 (emulate) -> there's this issue

## Issue description

parking_lot author:

> This seems to be closer to an LLVM bug than a parking_lot bug. The source
> of the problem is the CP15 emulation in the kernel. Essentially the
> mcr p15, #0x0, r12, c7, c10, #0x5 is trapping to the kernel every time,
> which invalidates the exclusive monitor between the ldrex and strex
> instructions. This results in the strex never succeeding and looping
> indefinitely.

See attached loop.png image.

ARM engineer (Will Deacon) response on this:

> Hi again, Robert,
> 
> Just a quick update on this:
>
>  1. CP15 barriers remain deprecated in the Armv8 architecture, and so
>    may be removed entirely from future CPUs.
>
> 2. Because of (1), the kernel defaults to trap+emulate, so that it can
>    warn about the use of these instructions. I think this is the right
>    thing to do because, once the instructions have been removed, we
>    will have no choice but to trap+emulate (this happened for the SWP
>    instruction already). This trapping will prevent your exclusives loop
>    from ever succeeding.
>
> 3. The right place to address this issue is in LLVM, where atomic
>    read-modify-write operations with conditional release semantics (i.e.
>    release on success) should actually emit the CP15 barrier before the
>    exclusives loop. Assuming that contention is rare (which it kind of
>    needs to be for performant compare-and-swap anyway), I don't see this
>    having a meaningful impact on performance.
>
> I've reached out to one of our upstream LLVM developers, and I'll be talking
> with him face-to-face next week about getting this fixed.
>
> Will

## Solution

Will's third point:

> Atomic read-modify-write operations with conditional release semantics (i.e.
> release on success) should actually emit the CP15 barrier before the
> exclusives loop. Assuming that contention is rare (which it kind of
> needs to be for performant compare-and-swap anyway), I don't see this
> having a meaningful impact on performance.

## No fix

People aren't / won't be able to use Rust / Swift / ... on Linux with
CP15_BARRIER_EMULATION=y & abi.cp15_barrier=1 (emulation, default value)
& arm-unknown-linux-gnueabihf toolchain.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190513/68ea6b68/attachment-0001.html>