Skip to content

Detecting races when releasing Tree Borrows protectors? #3266

@Imberflur

Description

@Imberflur

IIUC in tree borrows protectors generate implicit reads when they are released. However, the data race detector doesn't seem to be aware of them. Does it make sense for these to be accesses for the data race model?

This looks like a similar issue #2648

Here is an example I tested with MIRIFLAGS="-Zmiri-tree-borrows" cargo miri run.

use core::sync::atomic::AtomicBool;
use core::sync::atomic::Ordering;
use std::alloc;

static FLAG: AtomicBool = AtomicBool::new(false);

fn protector_data_race(v: &u8) {
    println!("{v}");
    FLAG.store(true, Ordering::Release);
    // Implicit read from protector not detected as a data race(?), but uncommenting this will be
    // detected:
    //println!("{v}");
}

fn main() {
    let layout = alloc::Layout::new::<u8>();
    let ptr = unsafe { alloc::alloc(layout) };
    assert!(!ptr.is_null());
    unsafe { *ptr = 8 };

    struct SendPtr(*mut u8);
    unsafe impl Send for SendPtr {}
    let send_ptr = SendPtr(ptr);

    std::thread::spawn(|| {
        let send_ptr = send_ptr;
        let r = unsafe { &*send_ptr.0 };
        protector_data_race(r);
    });

    loop {
        if FLAG.load(Ordering::Acquire) {
            // There is an actual race since we need to delay here to prevent the dealloc from
            // running while the protector still exists (generating a different kind of error).
            //
            // But we want to preserve the race to test the race detector... so this just loops,
            // perhaps there is a better and less fragile way to do this.
            for _ in 0..100 {}
            unsafe { alloc::dealloc(ptr.cast(), layout) };
            break;
        }
    }
}

The relevant code seems to be:

pub fn release_protector(

for (perms_range, perms) in self.rperms.iter_mut_all() {

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-aliasingArea: This affects the aliasing model (Stacked/Tree Borrows)A-data-raceArea: data race detectorC-spec-questionCategory: it is unclear what the intended behavior of Miri for this case is

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions