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

Detect simultaneous borrow and drop of UnsafeCell #351

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 21 additions & 1 deletion src/cell/unsafe_cell.rs
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
use std::mem::ManuallyDrop;

use crate::rt;

/// A checked version of `std::cell::UnsafeCell`.
Expand Down Expand Up @@ -115,7 +117,18 @@ impl<T> UnsafeCell<T> {

/// Unwraps the value.
pub fn into_inner(self) -> T {
self.data.into_inner()
// Observe that we have mutable access.
self.get_mut();

// We would like to destructure self. This is not possible because of
// the Drop implementation. Work around it using unsafe. Note that we
// extract `self.state` even though we don't use it. This prevents it
// from leaking.
let self_ = ManuallyDrop::new(self);
let _state = unsafe { std::ptr::read(&self_.state) };
let data = unsafe { std::ptr::read(&self_.data) };

data.into_inner()
}
}

Expand Down Expand Up @@ -214,6 +227,13 @@ impl<T> From<T> for UnsafeCell<T> {
}
}

impl<T: ?Sized> Drop for UnsafeCell<T> {
fn drop(&mut self) {
// Observe that we have mutable access.
self.get_mut();
Comment on lines +232 to +233
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should std::mem::needs_drop() be used to solve this issue:

You restrict the type's use relative to std's UnsafeCell. When Drop is implemented, drop check applies, making some uses that worked before no longer work.

Suggested change
// Observe that we have mutable access.
self.get_mut();
// Observe that we have mutable access if the inner type needs to be dropped.
if std::mem::needs_drop::<T>() {
self.get_mut();
}

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't agree with this.

  1. Even if the inner type doesn't need to be dropped and thus its drop implementation does nothing, dropping the cell while a reference to the inner type exists is still wrong.

  2. The documentation for needs_drop says that "this is purely an optimization hint". But we're changing observable behavior here. Using it would lead to safety assertions changing whether they get triggered based on the return value of needs_drop, which can change.

Copy link

@wyfo wyfo Jul 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if the inner type doesn't need to be dropped and thus its drop implementation does nothing, dropping the cell while a reference to the inner type exists is still wrong.

Actually, this is isn't wrong to me. If an object is dropped, it means that all references pointing to it have reach the end of their lifetime, otherwise, the code wouldn't even compile.
In fact, after thinking a second time about this sentence, it means that #349 is not an issue after all, and doesn't need to be "fixed".

My bad, the abstraction around UnsafeCell makes me forget that it was about pointers and not references.

Copy link

@wyfo wyfo Jul 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The documentation for needs_drop says that "this is purely an optimization hint". But we're changing observable behavior here.

This is an optimization hint, but the documentation still states "However if this function actually returns false, then you can be certain dropping T has no side effect". So needs_drop result is still guaranteed to have no false-negative, and can be relied on.
Of course, as written in the documentation, it could lead to false-positives, but a few false positive may be still better than a too much conservative behavior leading to more false-positives. And if the result of needs_drop is changing with compiler versions, it's still guaranteed to not introduce false-negative.

Copy link

@wyfo wyfo Jul 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway, see my comment in the issue, I don't think loom is doing things right here. Dropping a cell should not be counted a mutable access but as a cell invalidation, for further ConstPtr/MutPtr dereference.

}
}

impl<T: ?Sized> ConstPtr<T> {
/// Dereference the raw pointer.
///
Expand Down
25 changes: 25 additions & 0 deletions tests/unsafe_cell.rs
Original file line number Diff line number Diff line change
Expand Up @@ -60,8 +60,11 @@ fn atomic_causality_success() {
});
}

// This test is ignored because it causes an abort because of a double panic.
// More discussion at https://github.com/tokio-rs/loom/issues/350 .
#[test]
#[should_panic]
#[ignore]
fn atomic_causality_fail() {
struct Chan {
data: UnsafeCell<usize>,
Expand Down Expand Up @@ -333,3 +336,25 @@ fn unsafe_cell_access_after_sync() {
}
});
}

#[test]
#[should_panic]
fn unsafe_cell_access_during_drop() {
loom::model(|| {
let x = UnsafeCell::new(());
let _guard = x.get();
drop(x);
});
}

// Unfortunately we cannot repeat the previous test with `into_inner` instead of
// Drop because it leads to a second panic when UnsafeCell::drop runs and guard
// is still alive. The second panic leads to an abort.

#[test]
fn unsafe_cell_into_inner_ok() {
loom::model(|| {
let x = UnsafeCell::new(0usize);
x.into_inner();
});
}