[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZuUtFQ9zs6jJkasD@boqun-archlinux>
Date: Fri, 13 Sep 2024 23:28:37 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: Alice Ryhl <aliceryhl@...gle.com>, Miguel Ojeda <ojeda@...nel.org>,
Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>,
Andreas Hindborg <a.hindborg@...sung.com>,
Trevor Gross <tmgross@...ch.edu>,
Martin Rodriguez Reboredo <yakoyoku@...il.com>,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH] rust: sync: fix incorrect Sync bounds for LockedBy
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@...r.kernel.org
> > Fixes: 7b1f55e3a984 ("rust: sync: introduce `LockedBy`")
> > Signed-off-by: Alice Ryhl <aliceryhl@...gle.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@...ll.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@...gle.com>
> >
>
> --
> Simona Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
Powered by blists - more mailing lists