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

Investigate unsound mapped RwLock write guard downgrading

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

维护者通常 1 天内回复

@orthur2 已经在做这个了。

开始于 2026年10月11日。

  • #365 来自 @orthur2 —— 未关闭

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
rust
领域
backend, testing-qa

调研方向

Start by reviewing MappedRwLockWriteGuard::downgrade and OwnedMappedRwLockWriteGuard::downgrade, along with the mapped-guard history in #65, #61, #62, and the closed proposal in #358. Run the safe reproducer under Miri and compare it with downgrading the original write guard before projecting a shared reference. Done means verifying the soundness concern and reaching an agreed API contract and solution.

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

描述

Summary

@orthur2 @jeffoodchain Could you help verify the soundness issue below and discuss the appropriate API contract and solution?

MappedRwLockWriteGuard::downgrade and OwnedMappedRwLockWriteGuard::downgrade retain a pointer obtained from an arbitrary mutable projection while allowing other readers of the original value. A safe-code reproducer triggers undefined behavior under Miri. This issue tracks verification and the solution; the attempted fix in #358 has been closed pending discussion.

Reproducer

The following entirely safe program reproduces the problem on commit 44fc2d8:

use asyncband::rwlock::{RwLock, RwLockWriteGuard};
use std::sync::Mutex;

fn main() {
    let lock = RwLock::new(Mutex::new(0u8));
    let write = RwLockWriteGuard::map(lock.try_write().unwrap(), |inner| {
        inner.get_mut().unwrap()
    });
    let read = write.downgrade();
    let shared = &*read;
    let outer = lock.try_read().unwrap();
    *outer.lock().unwrap() = 1;
    println!("{shared}");
}

Miri reports that the later mutable access through outer.lock() invalidates the shared reference. The corresponding owned mapped guard reproducer also fails.

Soundness concern

The mutable projection &mut T -> &mut U can reach interior-mutable storage using exclusive access, as Mutex::get_mut does here. After downgrading, another reader of the original T can mutate that storage through its interior-mutability API while the mapped guard still exposes &U.

Both Mutex<u8> and u8 are Send + Sync, so adding those bounds alone does not address this example. The expected behavior is that safe guard operations cannot permit mutation that invalidates a live shared reference.

History and possible solutions

  • #65 introduced both mapped downgrade methods; they first shipped in mea 0.4.2 on 2025-08-30 and remain present in v0.7.3. This is not new in 0.7.3.
  • #62 tracks the original write-lock downgrade request; #61 contains the preceding mapped-guard work and follow-up discussion.
  • #358 contains the reproduction analysis and a proposed removal, but is closed pending agreement on the solution.

Keeping all exclusive permits appears sound but continues blocking readers, changing the downgrade contract. Downgrading the original write guard before applying a shared projection is another option: RwLockReadGuard::map(write.downgrade(), |root| &root.field) retains the lock throughout. A convenience API accepting a projection from the original &T could express the same boundary, but cannot simply reuse an arbitrary mutable projection.

Could you confirm whether the reproducer and reasoning establish that these APIs are unsound, and help decide whether to remove mapped downgrading or support it under a different contract?

主要语言
Rust
星标
277
派生
44
平均合并
1 天 1 小时
30 天内合并 PR
41

环境准备

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

从这里开始

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

apache/asyncband 的其他 Issue

查看 apache/asyncband 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

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