From: Danilo Krummrich <dakr@kernel.org>
To: Matthew Maurer <mmaurer@google.com>
Cc: "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>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Sami Tolvanen" <samitolvanen@google.com>,
"Timur Tabi" <ttabi@nvidia.com>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v3 2/4] rust: debugfs: Bind file creation for long-lived Display
Date: Fri, 2 May 2025 08:52:14 +0200 [thread overview]
Message-ID: <aBRrniLfCzWX7nbR@pollux> (raw)
In-Reply-To: <20250501-debugfs-rust-v3-2-850869fab672@google.com>
On Thu, May 01, 2025 at 10:47:42PM +0000, Matthew Maurer wrote:
> +/// Handle to a DebugFS file.
> +#[repr(transparent)]
> +pub struct File(ManuallyDrop<Dir>);
Same as with SubDir, please keep your original approach with keep().
Exposing this as a separate type is much better, but I still find it a bit weird
that it uses Dir internally, which still provides methods that are not
applicable.
I think it would be good to have the following types instead:
// Generic wrapper around the dentry pointer.
struct Entry;
// Based on Entry; provides Dir specific methods.
struct Dir;
// Based on Dir; implements Keep.
struct SubDir;
// Based on Entry; implements Keep.
struct File;
// Common trait that implements keep().
trait Keep;
> +impl File {
> + /// Remove the file from DebugFS.
> + ///
> + /// # Examples
> + /// ```
> + /// # use kernel::c_str;
> + /// # use kernel::debugfs::Dir;
> + /// let dir = Dir::new(c_str!("foo"));
> + /// {
> + /// let file = dir.display_file(c_str!("bar"), &0);
> + /// // "foo/bar" is created.
> + /// }
> + /// // "foo/bar" still exists.
> + /// {
> + /// let file = dir.display_file(c_str!("baz"), &0);
> + /// // "foo/baz" is created.
> + /// file.remove();
> + /// // "foo/baz" is gone.
> + /// }
> + pub fn remove(self) {
> + drop(ManuallyDrop::into_inner(self.0))
> + }
> +}
Same as with my comment on Dir::subdir(), it really gets confusing if we invert
the normal drop() logic. Removing the file when it is dropped and keeping it
when calling keep() is much more intuitive..
> +
> +#[cfg(CONFIG_DEBUG_FS)]
> +mod helpers {
> + use crate::seq_file::SeqFile;
> + use crate::seq_print;
> + use core::fmt::Display;
> +
> + /// Implements `open` for `file_operations` via `single_open` to fill out a `seq_file`.
> + ///
> + /// # Safety
> + ///
> + /// * `inode`'s private pointer must point to a value of type `T` which will outlive the `inode`
> + /// and will not be mutated during this call.
> + /// * `file` must point to a live, not-yet-initialized file object.
> + pub(crate) unsafe extern "C" fn display_open<T: Display>(
> + inode: *mut bindings::inode,
> + file: *mut bindings::file,
> + ) -> i32 {
> + // SAFETY:
> + // * `file` is acceptable by caller precondition.
> + // * `print_act` will be called on a `seq_file` with private data set to the third argument,
> + // so we meet its safety requirements.
> + // * The `data` pointer passed in the third argument is a valid `T` pointer that outlives
> + // this call by caller preconditions.
> + unsafe { bindings::single_open(file, Some(display_act::<T>), (*inode).i_private) }
Please split up unsafe operations.
> + }
> +
> + /// Prints private data stashed in a seq_file to that seq file.
> + ///
> + /// # Safety
> + ///
> + /// `seq` must point to a live `seq_file` whose private data is a live pointer to a `T` which is
> + /// not being mutated.
> + pub(crate) unsafe extern "C" fn display_act<T: Display>(
> + seq: *mut bindings::seq_file,
> + _: *mut core::ffi::c_void,
> + ) -> i32 {
> + // SAFETY: By caller precondition, this pointer is live, points to a value of type `T`, and
> + // is not being mutated.
> + let data = unsafe { &*((*seq).private as *mut T) };
This creates an intermediate reference to private, which is UB. Please use
addr_of! instead.
next prev parent reply other threads:[~2025-05-02 6:52 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-01 22:47 [PATCH v3 0/4] rust: DebugFS Bindings Matthew Maurer
2025-05-01 22:47 ` [PATCH v3 1/4] rust: debugfs: Bind DebugFS directory creation Matthew Maurer
2025-05-02 6:37 ` Danilo Krummrich
2025-05-02 7:00 ` Greg Kroah-Hartman
2025-05-02 7:05 ` Danilo Krummrich
2025-05-02 7:11 ` Greg Kroah-Hartman
2025-05-02 7:33 ` Danilo Krummrich
2025-05-02 7:39 ` Danilo Krummrich
2025-05-02 11:55 ` Greg Kroah-Hartman
2025-05-02 16:13 ` Matthew Maurer
2025-05-02 15:48 ` Matthew Maurer
2025-05-03 11:58 ` Danilo Krummrich
2025-05-02 8:12 ` Benno Lossin
2025-05-02 11:36 ` Greg Kroah-Hartman
2025-05-01 22:47 ` [PATCH v3 2/4] rust: debugfs: Bind file creation for long-lived Display Matthew Maurer
2025-05-02 6:52 ` Danilo Krummrich [this message]
2025-05-02 18:07 ` Matthew Maurer
2025-05-03 12:14 ` Danilo Krummrich
2025-05-01 22:47 ` [PATCH v3 3/4] rust: debugfs: Support format hooks Matthew Maurer
2025-05-01 22:47 ` [PATCH v3 4/4] rust: samples: Add debugfs sample Matthew Maurer
2025-05-02 7:01 ` Danilo Krummrich
2025-05-02 7:13 ` Greg Kroah-Hartman
2025-05-02 7:44 ` Danilo Krummrich
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=aBRrniLfCzWX7nbR@pollux \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmaurer@google.com \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=samitolvanen@google.com \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).