Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

memory clobber, barriers, fences

未关闭
  • 哪里不对？
#697 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

@jordens 已经在做这个了。

开始于 2026年10月16日。

  • #1261 来自 @jordens —— 未关闭

评估

难度
4/5
预计耗时
3-5 天
新手友好度
45/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
rust
领域
embedded-iot

调研方向

Start by reading the asm!() calls in src/interrupt.rs, src/register/control.rs, and src/asm.rs referenced in the issue, then check the Rust inline assembly rules for nomem and the compiler limitation in rust-lang/rust#144351. Review which calls need memory clobbers and the proposed fences around BASEPRI writes; done means the affected operations prevent memory accesses from moving across them and the changes are covered by appropriate tests. The issue calls out no test files.

由索引模型根据 Issue 内容生成。

描述

In 0.7.8 and 0.7.9 many of the asm!() calls that we expose as public API are marked as non memory clobbering via nomem (since #372). That allows the compiler to move these accesses around and especially through other memory accesses.

At face value, e.g. a cpsid, cpsie, or basepri writes indeed do not touch any memory or perform inter-thread synchronization and nomem appears completely adequate (see the language reference).
But in practice leaving it at that appears highly dangerous and a massive footgun. In all the cases that I can come up with these writes specifically want to disable/enable access to memory before/after some non-atomic op is performed on that memory. In these cases the user currently has to manually prevent the compiler from moving the write into or even across the non-atomic op. Not doing that demonstrably leads to issues like in rtic.

That burden alone is arguably already a bad idea and e.g. CMSIS tries very hard to not leave it to the user. But it gets worse: the right tool for that manual optimization protection isn't readily identified. Some other asm!() writes have compiler fences of varying shape (mostly SeqCst). Yet others are marked as memory clobbering (#526/#502 removed nomem again from isb, dsb, dmb). The third option would be to place traditional "barriers", in the form of empty memory clobbers asm!("", options(nostack, preserves_flags)) (e.g. like linux arm64 or interestingly also linux rust).

We should remove nomem from several asm!() calls for the following reasons:

  • Mask instructions do not themselves access memory, but the context predominantly needs to prevent memory accesses from moving across the masking/unmasking op
  • control::write changes processor state and does ISB. Surrounding memory accesses must execute in the intended privilege context
  • The code entered by bootstrap may read the initialized stack
  • During the semihosting bkpt the host may read or write memory through the argument pointer
  • Coprocessor transfers access state that may also be accessible through memory loads and stores (see e.g. Cortex-M33 TRM B6.6)

Downstream crates that want to be compatible with cortex-m 0.7.[89] should consider a hotfix with a asm!("", options(nostack, preserves_flags)) barrier pair.

A compiler fence is strictly speaking not the right tool here. It only "establishes synchronization with other atomic operations and fences". And neither the ops above nor the memory acess that we want to protect are atomic operations. That's the on-paper pessimistic view. In practice LLVM is more defensive and "AA (Alias Analysis) will return ModRef (potentially touching memory) for anything Acquire or Release". That's then surfaced for most outcomes of getSyncEffects() and typically leads to a memory barrier. But we should not rely on it. For more detail on this see https://github.com/rust-lang/unsafe-code-guidelines/issues/347.

But then again the memory clobber barrier (be it !nomem on the workhorse asm!() or a separate empty asm barrier) alone is currently also demonstrably imperfect at least in some situations due to a compiler limitation. I tried this with a BASEPRI example that publishes a pointer after leaving the critical section, similar to that issue. With memory clobbers alone, the compiler still elides initialization.

Therefore we should also add fences to work around the compiler bug:

  • Add Release before BASEPRI writes and Acquire afterwards
  • BASEPRI_MAX cannot weaken the mask and only needs Acquire afterwards

Comments welcome.

主要语言
Rust
星标
1k
派生
201
平均合并
5 小时 8 分钟
30 天内合并 PR
3

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

rust-embedded/cortex-m 的其他 Issue

查看 rust-embedded/cortex-m 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。