On Fri, Sep 13, 2024 at 08:45:16PM +0200, Simona Vetter wrote:
On Thu, Sep 12, 2024 at 02:20:06PM +0000, Alice Ryhl wrote:
The `impl Sync for LockedBy` implementation has insufficient trait bounds, as it only requires `T: Send`. However, `T: Sync` is also required for soundness because the `LockedBy::access` method could be used to provide shared access to the inner value from several threads in parallel.
Cc: stable@vger.kernel.org Fixes: 7b1f55e3a984 ("rust: sync: introduce `LockedBy`") Signed-off-by: Alice Ryhl aliceryhl@google.com
So I was pondering this forever, because we don't yet have read locks and for exclusive locks Send is enough. But since Arc<T> allows us to build really funny read locks already we need to require Sync for LockedBy, unlike Lock.
We could split access and access_mut up with a newtype so that Sync is only required when needed, but that's not too hard to sneak in when we actually need it.
Hmm.. I think it makes more sense to make `access()` requires `where T: Sync` instead of the current fix? I.e. I propose we do:
impl<T, U> LockedBy<T, U> { pub fn access<'a>(&'a self, owner: &'a U) -> &'a T where T: Sync { ... } }
The current fix in this patch disallows the case where a user has a `Foo: !Sync`, but want to have multiple `&LockedBy<Foo, X>` in different threads (they would use `access_mut()` to gain unique accesses), which seems to me is a valid use case.
The where-clause fix disallows the case where a user has a `Foo: !Sync`, a `&LockedBy<Foo, X>` and a `&X`, and is trying to get a `&Foo` with `access()`, this doesn't seems to be a common usage, but maybe I'm missing something?
Thoughts?
Regards, Boqun
Reviewed-by: Simona Vetter simona.vetter@ffwll.ch
rust/kernel/sync/locked_by.rs | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/rust/kernel/sync/locked_by.rs b/rust/kernel/sync/locked_by.rs index babc731bd5f6..153ba4edcb03 100644 --- a/rust/kernel/sync/locked_by.rs +++ b/rust/kernel/sync/locked_by.rs @@ -83,9 +83,10 @@ pub struct LockedBy<T: ?Sized, U: ?Sized> { // SAFETY: `LockedBy` can be transferred across thread boundaries iff the data it protects can. unsafe impl<T: ?Sized + Send, U: ?Sized> Send for LockedBy<T, U> {} -// SAFETY: `LockedBy` serialises the interior mutability it provides, so it is `Sync` as long as the -// data it protects is `Send`. -unsafe impl<T: ?Sized + Send, U: ?Sized> Sync for LockedBy<T, U> {} +// SAFETY: Shared access to the `LockedBy` can provide both `&mut T` references in a synchronized +// manner, or `&T` access in an unsynchronized manner. The `Send` trait is sufficient for the first +// case, and `Sync` is sufficient for the second case. +unsafe impl<T: ?Sized + Send + Sync, U: ?Sized> Sync for LockedBy<T, U> {} impl<T, U> LockedBy<T, U> { /// Constructs a new instance of [`LockedBy`]. @@ -127,7 +128,7 @@ pub fn access<'a>(&'a self, owner: &'a U) -> &'a T { panic!("mismatched owners"); }
// SAFETY: `owner` is evidence that the owner is locked.
// SAFETY: `owner` is evidence that there are only shared references to the owner. unsafe { &*self.data.get() }
base-commit: 93dc3be19450447a3a7090bd1dfb9f3daac3e8d2 change-id: 20240912-locked-by-sync-fix-07193df52f98
Best regards,
Alice Ryhl aliceryhl@google.com
-- Simona Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch