<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - CP15 barrier instructions should be emitted before the exclusives loops"
href="https://bugs.llvm.org/show_bug.cgi?id=41856">41856</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>CP15 barrier instructions should be emitted before the exclusives loops
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>rvojta@me.com
</td>
</tr>
<tr>
<th>CC</th>
<td>htmldeveloper@gmail.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=21941" name="attach_21941" title="Never ending loop">attachment 21941</a> <a href="attachment.cgi?id=21941&action=edit" title="Never ending loop">[details]</a></span>
Never ending loop
## Symptoms
* Rustup hangs (unable to install Rust)
* Tracked down to parking_lot issue:
<a href="https://github.com/Amanieu/parking_lot/issues/130">https://github.com/Amanieu/parking_lot/issues/130</a>
* Not just Rust related, Swift has this problem as well
*
<a href="https://forums.balena.io/t/cloud-build-fails-but-local-device-build-works-on-raspberry-pi-zero/4994">https://forums.balena.io/t/cloud-build-fails-but-local-device-build-works-on-raspberry-pi-zero/4994</a>
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:
<a href="https://www.kernel.org/doc/Documentation/arm64/legacy_instructions.txt">https://www.kernel.org/doc/Documentation/arm64/legacy_instructions.txt</a>
* 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:
<span class="quote">> 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.</span >
See attached loop.png image.
ARM engineer (Will Deacon) response on this:
<span class="quote">> Hi again, Robert,
>
> Just a quick update on this:</span >
>
<span class="quote">> 1. CP15 barriers remain deprecated in the Armv8 architecture, and so
> may be removed entirely from future CPUs.</span >
>
<span class="quote">> 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.</span >
>
<span class="quote">> 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.</span >
>
<span class="quote">> 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.</span >
>
<span class="quote">> Will</span >
## Solution
Will's third point:
<span class="quote">> 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.</span >
## 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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>