From: Alice Ryhl <aliceryhl@google.com>
To: Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Christian Brauner <brauner@kernel.org>
Cc: "Jens Axboe" <axboe@kernel.dk>, "Miguel Ojeda" <ojeda@kernel.org>,
"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>,
"Trevor Gross" <tmgross@umich.edu>,
rust-for-linux@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Christian Brauner" <brauner@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>
Subject: [PATCH v2] cred: rust: mark Credential methods inline
Date: Tue, 04 Mar 2025 10:25:13 +0000 [thread overview]
Message-ID: <20250304-inline-cred-v2-1-7aa54011bcab@google.com> (raw)
When you build the kernel using the llvm-19.1.4-rust-1.83.0-x86_64
toolchain provided by kernel.org with ARCH=arm64, the following symbols
are generated:
$ nm out-linux/vmlinux | grep ' _R'.*Credential | rustfilt
ffffffc0808fc540 T <kernel::cred::Credential>::get_secid
ffffffc0808fc588 T <kernel::cred::Credential as kernel::types::AlwaysRefCounted>::dec_ref
ffffffc0808fc570 T <kernel::cred::Credential as kernel::types::AlwaysRefCounted>::inc_ref
However, these Rust symbols are trivial wrappers around the functions
security_cred_getsecid, get_cred, and put_cred respectively. It doesn't
make sense to go through a trivial wrapper for these functions, so mark
them inline. Also mark other trivial methods inline to prevent similar
cases in the future.
After applying this patch, the above command will produce no output.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
Changes in v2:
- Reword commit message.
- Link to v1: https://lore.kernel.org/r/20250303-inline-cred-v1-1-b2527beace76@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 81d67789b16f243e7832ff3b2e5e479a1ab2bf9e..2599f01e8b285f2106aefd27c315ae2aff25293c 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 reply other threads:[~2025-03-04 10:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-04 10:25 Alice Ryhl [this message]
2025-03-04 22:07 ` Paul Moore
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=20250304-inline-cred-v2-1-7aa54011bcab@google.com \
--to=aliceryhl@google.com \
--cc=a.hindborg@kernel.org \
--cc=axboe@kernel.dk \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.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
all inboxes | Powered by JetHome®