From: Boqun Feng <boqun.feng@gmail.com>
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Paul Moore" <paul@paul-moore.com>,
"James Morris" <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"Christian Brauner" <brauner@kernel.org>,
"Jens Axboe" <axboe@kernel.dk>, "Miguel Ojeda" <ojeda@kernel.org>,
"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>,
"Trevor Gross" <tmgross@umich.edu>,
rust-for-linux@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cred: rust: mark Credential methods inline
Date: Mon, 3 Mar 2025 07:51:59 -0800 [thread overview]
Message-ID: <Z8XQH0RN858VRWtm@tardis> (raw)
In-Reply-To: <20250303-inline-cred-v1-1-b2527beace76@google.com>
Hi Alice,
On Mon, Mar 03, 2025 at 03:28:50PM +0000, Alice Ryhl wrote:
> I'm seeing Binder generating calls to methods on Credential such as
I would suggest using impersonal facts to explain why the changes are
needed. For example, you can show a compile result (with the version of
rust provided), which has the function callsites, in this way, it'll be
easy for people to verify this on their own. Thanks!
With this changed, feel free to add
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Regards,
Boqun
> get_secid, inc_ref, and dec_ref without inlining. Since these methods
> are really simple wrappers around C functions, mark the methods to
> inline to avoid generating these useless small functions.
>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> rust/kernel/cred.rs | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/rust/kernel/cred.rs b/rust/kernel/cred.rs
> index 81d67789b16f..2599f01e8b28 100644
> --- a/rust/kernel/cred.rs
> +++ b/rust/kernel/cred.rs
> @@ -47,6 +47,7 @@ impl Credential {
> ///
> /// The caller must ensure that `ptr` is valid and remains valid for the lifetime of the
> /// returned [`Credential`] reference.
> + #[inline]
> pub unsafe fn from_ptr<'a>(ptr: *const bindings::cred) -> &'a Credential {
> // SAFETY: The safety requirements guarantee the validity of the dereference, while the
> // `Credential` type being transparent makes the cast ok.
> @@ -54,6 +55,7 @@ pub unsafe fn from_ptr<'a>(ptr: *const bindings::cred) -> &'a Credential {
> }
>
> /// Get the id for this security context.
> + #[inline]
> pub fn get_secid(&self) -> u32 {
> let mut secid = 0;
> // SAFETY: The invariants of this type ensures that the pointer is valid.
> @@ -62,6 +64,7 @@ pub fn get_secid(&self) -> u32 {
> }
>
> /// Returns the effective UID of the given credential.
> + #[inline]
> pub fn euid(&self) -> Kuid {
> // SAFETY: By the type invariant, we know that `self.0` is valid. Furthermore, the `euid`
> // field of a credential is never changed after initialization, so there is no potential
> @@ -72,11 +75,13 @@ pub fn euid(&self) -> Kuid {
>
> // SAFETY: The type invariants guarantee that `Credential` is always ref-counted.
> unsafe impl AlwaysRefCounted for Credential {
> + #[inline]
> fn inc_ref(&self) {
> // SAFETY: The existence of a shared reference means that the refcount is nonzero.
> unsafe { bindings::get_cred(self.0.get()) };
> }
>
> + #[inline]
> unsafe fn dec_ref(obj: core::ptr::NonNull<Credential>) {
> // SAFETY: The safety requirements guarantee that the refcount is nonzero. The cast is okay
> // because `Credential` has the same representation as `struct cred`.
>
> ---
> base-commit: a64dcfb451e254085a7daee5fe51bf22959d52d3
> change-id: 20250303-inline-cred-1d1050785e5c
>
> Best regards,
> --
> Alice Ryhl <aliceryhl@google.com>
>
next prev parent reply other threads:[~2025-03-03 15:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <oBwtAqSRdc6GeLa0_12zYhVpYIQWZs7yGoDr17ZXC6X3aoPYIqkkMdWUbkgpU7sPS-FTUDaWEd4pYAuRawMJJQ==@protonmail.internalid>
2025-03-03 15:28 ` [PATCH] cred: rust: mark Credential methods inline Alice Ryhl
2025-03-03 15:51 ` Boqun Feng [this message]
2025-03-03 18:37 ` Andreas Hindborg
2025-03-04 9:31 ` Christian Brauner
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=Z8XQH0RN858VRWtm@tardis \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=axboe@kernel.dk \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=brauner@kernel.org \
--cc=gary@garyguo.net \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=paul@paul-moore.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=tmgross@umich.edu \
/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).