Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is stacked borrow too restrictive to be used with Pin? #527

Open
Medowhill opened this issue May 14, 2021 · 2 comments
Open

Is stacked borrow too restrictive to be used with Pin? #527

Medowhill opened this issue May 14, 2021 · 2 comments
Labels
cantfix This cannot be worked on because it can be resolved only after a proper fix in another project

Comments

@Medowhill
Copy link
Collaborator

rv6에 대한 이슈는 아니지만, 여기에 쓰는 편이 의견을 나누기 좋을 것 같아 여기에 씁니다.

Rust standard library Pin 문서의 self-referential struct 예시에는 다음과 같은 코드가 있습니다.

struct Unmovable {
    data: String,
    slice: NonNull<String>,
    _pin: PhantomPinned,
}

impl Unmovable {
    fn new(data: String) -> Pin<Box<Self>> {
        let res = Unmovable {
            data,
            slice: NonNull::dangling(),
            _pin: PhantomPinned,
        };
        let mut boxed = Box::pin(res);

        let slice = NonNull::from(&boxed.data);
        unsafe {
            let mut_ref: Pin<&mut Self> = Pin::as_mut(&mut boxed);
            Pin::get_unchecked_mut(mut_ref).slice = slice;
        }
        boxed
    }
}

Stacked borrow에 따르면 let slice = NonNull::from(&boxed.data);에서 만들어진 raw pointer는 바로 이후에 &mut boxed을 하면 무효화되기 때문에 slice를 사용하는 것은 UB입니다. 예를 들어, 다음과 같은 코드를 그냥 실행하면 hello가 출력되지만, Miri로 실행(-Zmiri-track-raw-pointers 플래그 필요)하면 unmoved.read()를 할 때 UB가 탐지됩니다.

impl Unmovable {
    fn read(&self) -> &String {
        unsafe { &*self.slice.as_ptr() }
    }
}

let unmoved = Unmovable::new("hello".to_string());
println!("{}", unmoved.read());

Standard library 문서에 나올 정도로 전형적이면서도 단순한 self-referential struct의 예시라고 생각되는데, 여기에조차 stacked borrow 관점에서 보았을 때 UB가 있다면, Rust에서 stacked borrow를 어기지 않으면서 self-referential struct를 만들 방법이 있는지 의문이 듭니다.

@jh05013
Copy link

jh05013 commented May 14, 2021

Related? rust-lang/unsafe-code-guidelines#148

@Medowhill Medowhill added cantfix This cannot be worked on because it can be resolved only after a proper fix in another project and removed D-hard labels Jun 4, 2021
@travis1829
Copy link
Collaborator

rust-lang/unsafe-code-guidelines#148 (comment)

  • 결국 저번달에 miri가 업데이트 된 이후로는 miri가 더 이상 !Unpin인 type에 대해서는 mutuable reference의 uniqueness를 가정하지 않는 것으로 보입니다. 확인해본 결과, 더 이상 ListRcCell 등이 miri에서 에러를 일으키지 않습니다. 이렇게 되면 StrongPinMut을 다시 없애야할 수 있을 것 같습니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cantfix This cannot be worked on because it can be resolved only after a proper fix in another project
Projects
None yet
Development

No branches or pull requests

4 participants