From: Wedson Almeida Filho <wedsonaf@gmail.com>
To: Benno Lossin <y86-dev@protonmail.com>
Cc: rust-for-linux@vger.kernel.org, "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
linux-kernel@vger.kernel.org,
"Wedson Almeida Filho" <walmeida@microsoft.com>
Subject: Re: [PATCH v3 13/13] rust: sync: introduce `LockedBy`
Date: Mon, 10 Apr 2023 23:57:14 -0300 [thread overview]
Message-ID: <ZDTMitCiFC/K4Rxw@wedsonaf-dev> (raw)
In-Reply-To: <6855e33f-445e-12b8-33e4-6b9559e16097@protonmail.com>
On Mon, Apr 10, 2023 at 07:52:02PM +0000, Benno Lossin wrote:
> On 08.04.23 09:53, Wedson Almeida Filho wrote:
> > From: Wedson Almeida Filho <walmeida@microsoft.com>
> >
> > This allows us to have data protected by a lock despite not being
> > wrapped by it. Access is granted by providing evidence that the lock is
> > held by the caller.
> >
> > Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
> > ---
> > v1 -> v2: Added build_assert to rule out zero-sized types
> > v2 -> v3: Improve comments around panics and support for ZSTs
> >
> > rust/kernel/sync.rs | 2 +
> > rust/kernel/sync/lock.rs | 2 +-
> > rust/kernel/sync/locked_by.rs | 147 ++++++++++++++++++++++++++++++++++
> > 3 files changed, 150 insertions(+), 1 deletion(-)
> > create mode 100644 rust/kernel/sync/locked_by.rs
> >
> > diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
> > index 431402180aa8..d219ee518eff 100644
> > --- a/rust/kernel/sync.rs
> > +++ b/rust/kernel/sync.rs
> > @@ -10,10 +10,12 @@ use crate::types::Opaque;
> > mod arc;
> > mod condvar;
> > pub mod lock;
> > +mod locked_by;
> >
> > pub use arc::{Arc, ArcBorrow, UniqueArc};
> > pub use condvar::CondVar;
> > pub use lock::{mutex::Mutex, spinlock::SpinLock};
> > +pub use locked_by::LockedBy;
> >
> > /// Represents a lockdep class. It's a wrapper around C's `lock_class_key`.
> > #[repr(transparent)]
> > diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
> > index c365bc909dff..84d8d7d01aaa 100644
> > --- a/rust/kernel/sync/lock.rs
> > +++ b/rust/kernel/sync/lock.rs
> > @@ -111,7 +111,7 @@ pub struct Lock<T: ?Sized, B: Backend> {
> > _pin: PhantomPinned,
> >
> > /// The data protected by the lock.
> > - data: UnsafeCell<T>,
> > + pub(crate) data: UnsafeCell<T>,
> > }
> >
> > // SAFETY: `Lock` can be transferred across thread boundaries iff the data it protects can.
> > diff --git a/rust/kernel/sync/locked_by.rs b/rust/kernel/sync/locked_by.rs
> > new file mode 100644
> > index 000000000000..ab0ecb013f54
> > --- /dev/null
> > +++ b/rust/kernel/sync/locked_by.rs
> > @@ -0,0 +1,147 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +//! A wrapper for data protected by a lock that does not wrap it.
> > +
> > +use super::{lock::Backend, lock::Lock};
> > +use core::{cell::UnsafeCell, ptr};
> > +
> > +/// Allows access to some data to be serialised by a lock that does not wrap it.
> > +///
> > +/// In most cases, data protected by a lock is wrapped by the appropriate lock type, e.g.,
> > +/// [`super::Mutex`] or [`super::SpinLock`]. [`LockedBy`] is meant for cases when this is not
> > +/// possible. For example, if a container has a lock and some data in the contained elements needs
> > +/// to be protected by the same lock.
> > +///
> > +/// [`LockedBy`] wraps the data in lieu of another locking primitive, and only allows access to it
> > +/// when the caller shows evidence that the 'external' lock is locked. It panics if the evidence
> > +/// refers to the wrong instance of the lock.
> > +///
>
> Maybe add a small section that ZSTs are not allowed for `U`,
> since they do not have to have unique addresses.
As I said on the previous message, the restriction that `U` cannot be a ZST is a
restriction of `access` and `access_mut`, it's not one of the struct.
Therefore, I don't think it belongs here.
In v3, I did add a small paragraph to both `access` and `access_mut` to reflect
this.
> > +/// # Examples
> > +///
> > +/// The following is an example for illustrative purposes: `InnerDirectory::bytes_used` is an
> > +/// aggregate of all `InnerFile::bytes_used` and must be kept consistent; so we wrap `InnerFile` in
> > +/// a `LockedBy` so that it shares a lock with `InnerDirectory`. This allows us to enforce at
> > +/// compile-time that access to `InnerFile` is only granted when an `InnerDirectory` is also
> > +/// locked; we enforce at run time that the right `InnerDirectory` is locked.
> > +///
> > +/// ```
> > +/// use kernel::sync::{LockedBy, Mutex};
> > +///
> > +/// struct InnerFile {
> > +/// bytes_used: u64,
> > +/// }
> > +///
> > +/// struct File {
> > +/// _ino: u32,
> > +/// inner: LockedBy<InnerFile, InnerDirectory>,
> > +/// }
> > +///
> > +/// struct InnerDirectory {
> > +/// /// The sum of the bytes used by all files.
> > +/// bytes_used: u64,
> > +/// _files: Vec<File>,
> > +/// }
> > +///
> > +/// struct Directory {
> > +/// _ino: u32,
> > +/// inner: Mutex<InnerDirectory>,
> > +/// }
> > +///
> > +/// /// Prints `bytes_used` from both the directory and file.
> > +/// fn print_bytes_used(dir: &Directory, file: &File) {
> > +/// let guard = dir.inner.lock();
> > +/// let inner_file = file.inner.access(&guard);
> > +/// pr_info!("{} {}", guard.bytes_used, inner_file.bytes_used);
> > +/// }
> > +///
> > +/// /// Increments `bytes_used` for both the directory and file.
> > +/// fn inc_bytes_used(dir: &Directory, file: &File) {
> > +/// let mut guard = dir.inner.lock();
> > +/// guard.bytes_used += 10;
> > +///
> > +/// let file_inner = file.inner.access_mut(&mut guard);
> > +/// file_inner.bytes_used += 10;
> > +/// }
> > +///
> > +/// /// Creates a new file.
> > +/// fn new_file(ino: u32, dir: &Directory) -> File {
> > +/// File {
> > +/// _ino: ino,
> > +/// inner: LockedBy::new(&dir.inner, InnerFile { bytes_used: 0 }),
> > +/// }
> > +/// }
> > +/// ```
> > +pub struct LockedBy<T: ?Sized, U: ?Sized> {
> > + owner: *const U,
> > + data: UnsafeCell<T>,
> > +}
> > +
> > +// 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> {}
> > +
> > +impl<T, U: ?Sized> LockedBy<T, U> {
> > + /// Constructs a new instance of [`LockedBy`].
> > + ///
> > + /// It stores a raw pointer to the owner that is never dereferenced. It is only used to ensure
> > + /// that the right owner is being used to access the protected data. If the owner is freed, the
> > + /// data becomes inaccessible; if another instance of the owner is allocated *on the same
> > + /// memory location*, the data becomes accessible again: none of this affects memory safety
> > + /// because in any case at most one thread (or CPU) can access the protected data at a time.
> > + pub fn new(owner: &Lock<U, impl Backend>, data: T) -> Self {
>
> I suggested this already on v2, but I think it was to late, since
> you quickly sent v3 after I sent my reply, so reiterating the point here.
>
> I think we should have `build_assert!(mem::size_of::<Lock<T, B>>() > 0)`
> here to ensure that you cannot have two locks referring to the same
> memory location.
Ok, I'll add this to v4.
> This is rather pedantic, since I doubt that we would introduce a
> `Backend` that has a ZST as the `State`, but it also does not hurt
> and might prevent a hard to identify bug later.
>
> > + Self {
> > + owner: owner.data.get(),
> > + data: UnsafeCell::new(data),
> > + }
> > + }
> > +}
> > +
> > +impl<T: ?Sized, U> LockedBy<T, U> {
> > + /// Returns a reference to the protected data when the caller provides evidence (via a
> > + /// reference) that the owner is locked.
> > + ///
> > + /// `U` cannot be a zero-sized type (ZST) because there are ways to get an `&U` that matches
> > + /// the data protected by the lock without actually holding it.
> > + ///
> > + /// # Panics
> > + ///
> > + /// Panics if `owner` is different from the data protected by the lock used in
> > + /// [`new`](LockedBy::new).
> > + pub fn access<'a>(&'a self, owner: &'a U) -> &'a T {
> > + // Detect the usage of SZTs, which are supported, at compile time.
>
> Typos: "SZTs" -> "ZSTs" and "supported" -> "unsupported"? Also found below.
Oh, thanks for spotting these!
>
> > + crate::build_assert!(core::mem::size_of::<U>() > 0);
>
> Could you add a meaningful error message here? Like
> "Cannot use `LockedBy` where `U` is a ZST, since it does
> not guarantee address uniqueness."
> Also add this in the calls to `build_assert!` below and above.
I'm adding a message and removing the comment I had above in v4. Note, however,
that this message isn't displayed when the build fails, so it is of limited use
at the moment. (We do get a file name and line number, which helps bringing
attention to the right place.)
>
> --
> Cheers,
> Benno
>
> > + if !ptr::eq(owner, self.owner) {
> > + panic!("mismatched owners");
> > + }
> > +
> > + // SAFETY: `owner` is evidence that the owner is locked.
> > + unsafe { &*self.data.get() }
> > + }
> > +
> > + /// Returns a mutable reference to the protected data when the caller provides evidence (via a
> > + /// mutable owner) that the owner is locked mutably.
> > + ///
> > + /// `U` cannot be a zero-sized type (ZST) because there are ways to get an `&mut U` that
> > + /// matches the data protected by the lock without actually holding it.
> > + ///
> > + /// Showing a mutable reference to the owner is sufficient because we know no other references
> > + /// can exist to it.
> > + ///
> > + /// # Panics
> > + ///
> > + /// Panics if `owner` is different from the data protected by the lock used in
> > + /// [`new`](LockedBy::new).
> > + pub fn access_mut<'a>(&'a self, owner: &'a mut U) -> &'a mut T {
> > + // Detect the usage of SZTs, which are supported, at compile time.
> > + crate::build_assert!(core::mem::size_of::<U>() > 0);
> > + if !ptr::eq(owner, self.owner) {
> > + panic!("mismatched owners");
> > + }
> > +
> > + // SAFETY: `owner` is evidence that there is only one reference to the owner.
> > + unsafe { &mut *self.data.get() }
> > + }
> > +}
> > --
> > 2.34.1
> >
>
next prev parent reply other threads:[~2023-04-11 2:57 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-08 7:53 [PATCH v3 01/13] rust: sync: introduce `LockClassKey` Wedson Almeida Filho
2023-04-08 7:53 ` [PATCH v3 02/13] rust: sync: introduce `Lock` and `Guard` Wedson Almeida Filho
2023-04-09 16:47 ` Martin Rodriguez Reboredo
2023-04-11 3:01 ` Wedson Almeida Filho
2023-04-08 7:53 ` [PATCH v3 03/13] rust: lock: introduce `Mutex` Wedson Almeida Filho
2023-04-09 16:47 ` Martin Rodriguez Reboredo
2023-04-08 7:53 ` [PATCH v3 04/13] locking/spinlock: introduce spin_lock_init_with_key Wedson Almeida Filho
2023-04-09 16:47 ` Martin Rodriguez Reboredo
2023-04-08 7:53 ` [PATCH v3 05/13] rust: lock: introduce `SpinLock` Wedson Almeida Filho
2023-04-09 16:48 ` Martin Rodriguez Reboredo
2023-04-08 7:53 ` [PATCH v3 06/13] rust: lock: add support for `Lock::lock_irqsave` Wedson Almeida Filho
2023-04-09 16:48 ` Martin Rodriguez Reboredo
2023-04-08 7:53 ` [PATCH v3 07/13] rust: lock: implement `IrqSaveBackend` for `SpinLock` Wedson Almeida Filho
2023-04-09 16:48 ` Martin Rodriguez Reboredo
2023-04-08 7:53 ` [PATCH v3 08/13] rust: introduce `ARef` Wedson Almeida Filho
2023-04-09 16:48 ` Martin Rodriguez Reboredo
2023-04-08 7:53 ` [PATCH v3 09/13] rust: add basic `Task` Wedson Almeida Filho
2023-04-09 16:48 ` Martin Rodriguez Reboredo
2023-04-08 7:53 ` [PATCH v3 10/13] rust: introduce `current` Wedson Almeida Filho
2023-04-09 16:48 ` Martin Rodriguez Reboredo
2023-04-10 18:04 ` Benno Lossin
2023-04-11 3:08 ` Wedson Almeida Filho
2023-04-08 7:53 ` [PATCH v3 11/13] rust: lock: add `Guard::do_unlocked` Wedson Almeida Filho
2023-04-09 16:49 ` Martin Rodriguez Reboredo
2023-04-08 7:53 ` [PATCH v3 12/13] rust: sync: introduce `CondVar` Wedson Almeida Filho
2023-04-09 16:49 ` Martin Rodriguez Reboredo
2023-04-11 2:59 ` Wedson Almeida Filho
2023-04-08 7:53 ` [PATCH v3 13/13] rust: sync: introduce `LockedBy` Wedson Almeida Filho
2023-04-09 16:49 ` Martin Rodriguez Reboredo
2023-04-10 17:46 ` Boqun Feng
2023-04-10 18:13 ` Boqun Feng
2023-04-10 19:52 ` Benno Lossin
2023-04-11 2:57 ` Wedson Almeida Filho [this message]
2023-04-09 16:46 ` [PATCH v3 01/13] rust: sync: introduce `LockClassKey` Martin Rodriguez Reboredo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZDTMitCiFC/K4Rxw@wedsonaf-dev \
--to=wedsonaf@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=walmeida@microsoft.com \
--cc=y86-dev@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.