Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Investigate unsound mapped RwLock write guard downgrading

オープン
  • 何か問題がありますか？
#362 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@orthur2 がすでに取り組んでいます。

2026年10月11日 から。

  • #365 @orthur2 による — オープン

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
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
スター
283
フォーク
49
平均マージ
10時間 58分
マージ済み PR（30日）
37

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/asyncband のほかの issue

apache/asyncband の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。