From: Boqun Feng <boqun.feng@gmail.com>
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Steven Rostedt" <rostedt@goodmis.org>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Josh Poimboeuf" <jpoimboe@kernel.org>,
"Jason Baron" <jbaron@akamai.com>,
"Ard Biesheuvel" <ardb@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Wedson Almeida Filho" <wedsonaf@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@samsung.com>,
linux-trace-kernel@vger.kernel.org,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org, "Arnd Bergmann" <arnd@arndb.de>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Peter Zijlstra (Intel)" <peterz@infradaed.org>,
"Sean Christopherson" <seanjc@google.com>,
"Uros Bizjak" <ubizjak@gmail.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>, "Marc Zyngier" <maz@kernel.org>,
"Oliver Upton" <oliver.upton@linux.dev>,
"Mark Rutland" <mark.rutland@arm.com>,
"Ryan Roberts" <ryan.roberts@arm.com>,
"Fuad Tabba" <tabba@google.com>,
linux-arm-kernel@lists.infradead.org,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Anup Patel" <apatel@ventanamicro.com>,
"Andrew Jones" <ajones@ventanamicro.com>,
"Alexandre Ghiti" <alexghiti@rivosinc.com>,
"Conor Dooley" <conor.dooley@microchip.com>,
"Samuel Holland" <samuel.holland@sifive.com>,
linux-riscv@lists.infradead.org,
"Huacai Chen" <chenhuacai@kernel.org>,
"WANG Xuerui" <kernel@xen0n.name>,
"Bibo Mao" <maobibo@loongson.cn>,
"Tiezhu Yang" <yangtiezhu@loongson.cn>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Tianrui Zhao" <zhaotianrui@loongson.cn>,
loongarch@lists.linux.dev
Subject: Re: [PATCH v3 1/2] rust: add static_key_false
Date: Tue, 25 Jun 2024 09:18:01 -0700 [thread overview]
Message-ID: <ZnrtuaUByT70tJY5@boqun-archlinux> (raw)
In-Reply-To: <20240621-tracepoint-v3-1-9e44eeea2b85@google.com>
Hi Alice,
On Fri, Jun 21, 2024 at 10:35:26AM +0000, Alice Ryhl wrote:
> Add just enough support for static key so that we can use it from
> tracepoints. Tracepoints rely on `static_key_false` even though it is
> deprecated, so we add the same functionality to Rust.
>
> It is not possible to use the existing C implementation of
> arch_static_branch because it passes the argument `key` to inline
> assembly as an 'i' parameter, so any attempt to add a C helper for this
> function will fail to compile because the value of `key` must be known
> at compile-time.
>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
[Add linux-arch, and related arch maintainers Cced]
Since inline asms are touched here, please consider copying linux-arch
and arch maintainers next time ;-)
> ---
> rust/kernel/lib.rs | 1 +
> rust/kernel/static_key.rs | 143 ++++++++++++++++++++++++++++++++++++++++++++++
> scripts/Makefile.build | 2 +-
> 3 files changed, 145 insertions(+), 1 deletion(-)
>
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index fbd91a48ff8b..a0be9544996d 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -38,6 +38,7 @@
> pub mod prelude;
> pub mod print;
> mod static_assert;
> +pub mod static_key;
> #[doc(hidden)]
> pub mod std_vendor;
> pub mod str;
> diff --git a/rust/kernel/static_key.rs b/rust/kernel/static_key.rs
> new file mode 100644
> index 000000000000..9c844fe3e3a3
> --- /dev/null
> +++ b/rust/kernel/static_key.rs
> @@ -0,0 +1,143 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +// Copyright (C) 2024 Google LLC.
> +
> +//! Logic for static keys.
> +
> +use crate::bindings::*;
> +
> +#[doc(hidden)]
> +#[macro_export]
> +#[cfg(target_arch = "x86_64")]
> +macro_rules! _static_key_false {
> + ($key:path, $keytyp:ty, $field:ident) => {'my_label: {
> + core::arch::asm!(
> + r#"
> + 1: .byte 0x0f,0x1f,0x44,0x00,0x00
> +
> + .pushsection __jump_table, "aw"
> + .balign 8
> + .long 1b - .
> + .long {0} - .
> + .quad {1} + {2} - .
> + .popsection
> + "#,
> + label {
> + break 'my_label true;
> + },
> + sym $key,
> + const ::core::mem::offset_of!($keytyp, $field),
> + );
> +
> + break 'my_label false;
> + }};
> +}
> +
> +#[doc(hidden)]
> +#[macro_export]
> +#[cfg(target_arch = "aarch64")]
> +macro_rules! _static_key_false {
> + ($key:path, $keytyp:ty, $field:ident) => {'my_label: {
> + core::arch::asm!(
> + r#"
> + 1: nop
> +
> + .pushsection __jump_table, "aw"
> + .align 3
> + .long 1b - ., {0} - .
> + .quad {1} + {2} - .
> + .popsection
> + "#,
> + label {
> + break 'my_label true;
> + },
> + sym $key,
> + const ::core::mem::offset_of!($keytyp, $field),
> + );
> +
> + break 'my_label false;
> + }};
> +}
> +
For x86_64 and arm64 bits:
Acked-by: Boqun Feng <boqun.feng@gmail.com>
One thing though, we should split the arch-specific impls into different
files, for example: rust/kernel/arch/arm64.rs or rust/arch/arm64.rs.
That'll be easier for arch maintainers to watch the Rust changes related
to a particular architecture.
Another thought is that, could you implement an arch_static_branch!()
(instead of _static_key_false!()) and use it for static_key_false!()
similar to what we have in C? The benefit is that at least for myself
it'll be easier to compare the implementation between C and Rust.
Regards,
Boqun
> +#[doc(hidden)]
> +#[macro_export]
> +#[cfg(target_arch = "loongarch64")]
> +macro_rules! _static_key_false {
> + ($key:path, $keytyp:ty, $field:ident) => {'my_label: {
> + core::arch::asm!(
> + r#"
> + 1: nop
> +
> + .pushsection __jump_table, "aw"
> + .align 3
> + .long 1b - ., {0} - .
> + .quad {1} + {2} - .
> + .popsection
> + "#,
> + label {
> + break 'my_label true;
> + },
> + sym $key,
> + const ::core::mem::offset_of!($keytyp, $field),
> + );
> +
> + break 'my_label false;
> + }};
> +}
> +
> +#[doc(hidden)]
> +#[macro_export]
> +#[cfg(target_arch = "riscv64")]
> +macro_rules! _static_key_false {
> + ($key:path, $keytyp:ty, $field:ident) => {'my_label: {
> + core::arch::asm!(
> + r#"
> + .align 2
> + .option push
> + .option norelax
> + .option norvc
> + 1: nop
> + .option pop
> + .pushsection __jump_table, "aw"
> + .align 3
> + .long 1b - ., {0} - .
> + .dword {1} + {2} - .
> + .popsection
> + "#,
> + label {
> + break 'my_label true;
> + },
> + sym $key,
> + const ::core::mem::offset_of!($keytyp, $field),
> + );
> +
> + break 'my_label false;
> + }};
> +}
> +
> +/// Branch based on a static key.
> +///
> +/// Takes three arguments:
> +///
> +/// * `key` - the path to the static variable containing the `static_key`.
> +/// * `keytyp` - the type of `key`.
> +/// * `field` - the name of the field of `key` that contains the `static_key`.
> +#[macro_export]
> +macro_rules! static_key_false {
> + // Forward to the real implementation. Separated like this so that we don't have to duplicate
> + // the documentation.
> + ($key:path, $keytyp:ty, $field:ident) => {{
> + // Assert that `$key` has type `$keytyp` and that `$key.$field` has type `static_key`.
> + //
> + // SAFETY: We know that `$key` is a static because otherwise the inline assembly will not
> + // compile. The raw pointers created in this block are in-bounds of `$key`.
> + static _TY_ASSERT: () = unsafe {
> + let key: *const $keytyp = ::core::ptr::addr_of!($key);
> + let _: *const $crate::bindings::static_key = ::core::ptr::addr_of!((*key).$field);
> + };
> +
> + $crate::_static_key_false! { $key, $keytyp, $field }
> + }};
> +}
> +
> +pub use static_key_false;
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index efacca63c897..60197c1c063f 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -263,7 +263,7 @@ $(obj)/%.lst: $(obj)/%.c FORCE
> # Compile Rust sources (.rs)
> # ---------------------------------------------------------------------------
>
> -rust_allowed_features := new_uninit
> +rust_allowed_features := asm_const,asm_goto,new_uninit
>
> # `--out-dir` is required to avoid temporaries being created by `rustc` in the
> # current working directory, which may be not accessible in the out-of-tree
>
> --
> 2.45.2.741.gdbec12cfda-goog
>
next prev parent reply other threads:[~2024-06-25 16:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-21 10:35 [PATCH v3 0/2] Tracepoints and static branch in Rust Alice Ryhl
2024-06-21 10:35 ` [PATCH v3 1/2] rust: add static_key_false Alice Ryhl
2024-06-25 16:18 ` Boqun Feng [this message]
2024-06-27 8:34 ` Alice Ryhl
2024-06-27 16:26 ` Boqun Feng
2024-06-21 10:35 ` [PATCH v3 2/2] rust: add tracepoint support Alice Ryhl
2024-06-21 12:52 ` Alice Ryhl
2024-06-25 18:10 ` Boqun Feng
2024-06-26 8:48 ` Alice Ryhl
2024-06-26 18:43 ` Steven Rostedt
2024-06-28 15:00 ` Alice Ryhl
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=ZnrtuaUByT70tJY5@boqun-archlinux \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@samsung.com \
--cc=ajones@ventanamicro.com \
--cc=akpm@linux-foundation.org \
--cc=alex.gaynor@gmail.com \
--cc=alexghiti@rivosinc.com \
--cc=aliceryhl@google.com \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=dave.hansen@linux.intel.com \
--cc=gary@garyguo.net \
--cc=hpa@zytor.com \
--cc=jbaron@akamai.com \
--cc=jpoimboe@kernel.org \
--cc=kernel@xen0n.name \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=maobibo@loongson.cn \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=maz@kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=ojeda@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradaed.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=ryan.roberts@arm.com \
--cc=samuel.holland@sifive.com \
--cc=seanjc@google.com \
--cc=tabba@google.com \
--cc=tglx@linutronix.de \
--cc=ubizjak@gmail.com \
--cc=wedsonaf@gmail.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=yangtiezhu@loongson.cn \
--cc=zhaotianrui@loongson.cn \
/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).