Repository navigation
csky targets' atomic RMW is not lock-free and may cause data races between load/store and it #117306
Description
Activity
- added
on Oct 28, 2023 Thanks!
I think to fix LLVM to generate atomic instructions instead of libcalls is a better idea.
The linux system and the gcc-toolchain of csky is not well maintained and the newest version of them is not open-source. Besides, there's many exsited devices with the system which is not suitable for upgrade.
Therefore, I think to fix LLVM is a more realizable and practical way.
Reacted by Taiki Endo(We don't have a CSky target label?)
I assume this is about the csky-unknown-linux-gnuabiv2 target.
I assume this is about the csky-unknown-linux-gnuabiv2 target.
and the csky-unknown-linux-gnuabiv2hf
WG-prioritization assigning priority (Zulip discussion).
@Dirreke AFAICS the compiler target
csky-unknown-linux-gnuabiv2hfis not mapped on our Tier support list. Do you think it should be updated?@rustbot label -I-prioritize +P-low
@Dirreke AFAICS the compiler target
csky-unknown-linux-gnuabiv2hfis not mapped on our Tier support list. Do you think it should be updated?csky-unknown-linux-gnuabiv2hfis introduced into rust at #117049 . The targetcsky-unknown-linux-gnuabiv2hfand the related docs will be released in the next version.Reacted by apirainoIt is not impossible to fix this on our end, but it is not very realistic as it would require writing a lot of inline assembly.
Btw, taiki-e/atomic-maybe-uninit#32 (not merged) has an experimental inline assembly based implementation. (However, I have not tested that, because the emulator described in the platform documentation always crashes.)
- Fix LLVM to generate atomic instructions instead of libcalls.
The results of the investigation in the atomic-maybe-uninit PR mentioned above indicate that this approach is likely insufficient for the soft float target (
csky-unknown-linux-gnuabiv2).In C-SKY, the ldex/stex instructions required for RMW are only available on certain CPUs (
ck860*) and cannot be used in the baseline for the soft float target1. (See the second part of taiki-e/atomic-maybe-uninit#32 (comment) for details.) The hard-float target (csky-unknown-linux-gnuabiv2hf)'s baseline2 is okay.This is a similar situation to pre-v6 Arm, and on pre-v6 Arm we implement atomics using helpers provided by the kernel.
C-SKY also seems to have a similar helper, but it doesn't seem to be exposed, so we probably can't adopt the same approach at this point.
Raising the baseline would make this approach okay, but that's may not the wanted way here. In that case, I think we'd need to expose kernel helpers like Arm does, but considering that it won't work on older kernels, I suspect it will take quite some time before the kernel helper approach can be used.
Footnotes
- changed the title
[-]csky targets' atomic RMW is not lock-free[/-][+]csky targets' atomic RMW is not lock-free and may cause data races between load/store [/+]on Jul 19, 2026 - changed the title
[-]csky targets' atomic RMW is not lock-free and may cause data races between load/store [/-][+]csky targets' atomic RMW is not lock-free and may cause data races between load/store and it[/+]on Jul 19, 2026
In csky, LLVM always generates libcalls (llvm/llvm-project@ec2de74), and atomic implementations are provided by libatomic.
rust/compiler/rustc_target/src/spec/csky_unknown_linux_gnuabiv2.rs
Line 15 in c7224e3
However, as mentioned in #115577 (comment), the atomic RMW implementation provided in libatomic.a is not lock-free.
And it violates what the standard library is intended to guarantee.
https://doc.rust-lang.org/nightly/std/sync/atomic/index.html#portability
Also, mixing lock-free load/store and non-lock-free RMW can cause data races.
To fix this, we would need to do one of the following:
It is not impossible to fix this on our end, but it is not very realistic as it would require writing a lot of inline assembly.
cc @Dirreke (mentioned because you are target maintainer)
@rustbot label +A-atomic +I-unsound