Add missing `#[inline]` markers to trivial wrappers around C functions #1145

Darksonn · 2025-03-05T13:10:11Z

When writing abstractions around core C apis, we often have Rust functions that do nothing other than call a C function. In those cases, we don't want the generated code to have a trivial Rust wrapper around the C function — Rust should inline it and generate a direct call into C.

However, in some cases that requires an #[inline] marker. Many methods in the kernel is missing it, and so this issue tracks such additions.

A few cases where I know that this is happening:

rust/kernel/task.rs
rust/kernel/page.rs
rust/kernel/sync/condvar.rs
rust/kernel/fs.rs specifically FileDescriptorReservation
rust/kernel/seq_file.rs
rust/kernel/uaccess.rs

To find these, you can inspect the Rust symbols yourself by building the kernel and running this command:

nm vmlinux | grep ' _R' | rustfilt

Examples of good patches that make this kind of change:

If you submit a patch that makes this kind of change, please make sure to have a good commit message (see the examples above).

This requires submitting a proper patch to the LKML and the Rust for Linux mailing list. Please recall to test your changes (including generating the documentation if changed, running the Rust doctests if changed, etc.), to use a proper title for the commit, to sign your commit under the Developer's Certificate of Origin and to add a Suggested-by: tag and a Link: tag to this issue. Please see https://docs.kernel.org/process/submitting-patches.html and https://rust-for-linux.com/contributing for details.

Please take this issue only if you are new to the kernel development process and you would like to use it as a test to submit your first patch to the kernel. Please do not take it if you do not plan to make other contributions to the kernel.

The text was updated successfully, but these errors were encountered:

panosfol · 2025-03-05T13:42:55Z

Hello! I would like to tackle this issue

ojeda · 2025-03-05T13:51:45Z

Thanks, please go ahead!

Darksonn · 2025-03-06T11:52:38Z

I recommend that you don't try to tackle every single method in one go. Start with one or two files and send a patch just for those, like the example patches did.

panosfol · 2025-03-06T11:53:38Z

Sounds good!

ethancedwards8 · 2025-03-10T02:20:11Z

Giving it a try: https://lkml.org/lkml/2025/3/9/512

When building the kernel on Arch Linux using on x86_64 with tools: $ rustc --version rustc 1.84.0 (9fc6b4312 2025-01-07) $ cargo --version cargo 1.84.0 (66221abde 2024-11-19) $ clang --version clang version 19.1.7 Target: x86_64-pc-linux-gnu The following symbols are generated: $ nm vmlinux | rg ' _R' | rustfilt | rg faux ffffffff81959ae0 T <kernel::faux::Registration>::new ffffffff81959b40 T <kernel::faux::Registration as core::ops::drop::Drop>::drop However, these Rust symbols are wrappers around bindings in the C faux code. Inlining these functions removes the middle-man wrapper function After applying this patch, the above function signatures disappear. Link: Rust-for-Linux#1145 Signed-off-by: Ethan Carter Edwards <[email protected]>

When you build the kernel using the llvm-18.1.3-rust-1.85.0-x86_64 toolchain provided by kernel.org, the following symbols are generated: $ nm vmlinux | grep ' _R'.*Task | rustfilt ffffffff817b2d30 T <kernel::task::Task>::get_pid_ns ffffffff817b2d50 T <kernel::task::Task>::tgid_nr_ns ffffffff817b2c90 T <kernel::task::Task>::current_pid_ns ffffffff817b2d00 T <kernel::task::Task>::signal_pending ffffffff817b2cc0 T <kernel::task::Task>::uid ffffffff817b2ce0 T <kernel::task::Task>::euid ffffffff817b2c70 T <kernel::task::Task>::current ffffffff817b2d70 T <kernel::task::Task>::wake_up ffffffff817b2db0 T <kernel::task::Task as kernel::types::AlwaysRefCounted>::dec_ref ffffffff817b2d90 T <kernel::task::Task as kernel::types::AlwaysRefCounted>::inc_ref Most of these Rust symbols are trivial wrappers around the C functions signal_pending, uid, euid, wake_up, dec_ref and inc_ref.It doesn't make sense to go through a trivial wrapper for these functions, so mark them inline. After applying this patch, the above command will produce this output: ffff8000805aa004 T <kernel::task::Task>::get_pid_ns ffff8000805aa01c T <kernel::task::Task>::tgid_nr_ns ffff8000805a9fe8 T <kernel::task::Task>::current_pid_ns ffff8000805a9fd0 T <kernel::task::Task>::current Signed-off-by: Panagiotis Foliadis <[email protected]> Link: Rust-for-Linux#1145

ojeda · 2025-03-10T17:01:49Z

Thanks both for the patches!

By the way, please prefer lore.kernel.org for links, e.g. @ethancedwards8's patch is: https://lore.kernel.org/rust-for-linux/[email protected]/

When building the kernel on Arch Linux using on x86_64 with tools: $ rustc --version rustc 1.84.0 (9fc6b4312 2025-01-07) $ cargo --version cargo 1.84.0 (66221abde 2024-11-19) $ clang --version clang version 19.1.7 Target: x86_64-pc-linux-gnu The following symbols are generated: $ nm vmlinux | rg ' _R' | rustfilt | rg faux ffffffff81959ae0 T <kernel::faux::Registration>::new ffffffff81959b40 T <kernel::faux::Registration as core::ops::drop::Drop>::drop However, these Rust symbols are wrappers around bindings in the C faux code. Inlining these functions removes the middle-man wrapper function After applying this patch, the above function signatures disappear. Link: Rust-for-Linux#1145 Signed-off-by: Ethan Carter Edwards <[email protected]>

ethancedwards8 · 2025-03-11T01:03:17Z

Thanks both for the patches!

By the way, please prefer lore.kernel.org for links, e.g. @ethancedwards8's patch is: https://lore.kernel.org/rust-for-linux/[email protected]/

Yeah, I typically use lore.kernel.org, but last night when I was sending the patch lore.kernel.org was having some issues (I was getting 504 errors), so I used lkml.org instead. I will use lore.kernel.org exclusively in the future, however

antonio-hickey · 2025-03-11T02:27:06Z

Giving a try for methods in uaccess.

https://lore.kernel.org/all/0100019582fc6956-3b420cce-f122-4a26-8fea-94000b22bc90-000000@email.amazonses.com

#1147

KunWuChan · 2025-03-11T06:46:18Z

When writing abstractions around core C apis, we often have Rust functions that do nothing other than call a C function. In those cases, we don't want the generated code to have a trivial Rust wrapper around the C function — Rust should inline it and generate a direct call into C.在围绕核心 C API 编写抽象时，我们经常会有 Rust 函数，它们除了调用 C 函数之外什么都不做。在这些情况下，我们不希望生成的代码在 C 函数周围有一个简单的 Rust 包装器——Rust 应该内联它并生成对 C 的直接调用。

However, in some cases that requires an #[inline] marker. Many methods in the kernel is missing it, and so this issue tracks such additions.但是，在某些情况下，这需要 #[inline] 标记。内核中的许多方法都缺少它，因此 issue 跟踪此类添加。

A few cases where I know that this is happening:我知道这种情况正在发生的一些情况：

rust/kernel/task.rs``rust/内核/task.rs

rust/kernel/page.rs

rust/kernel/sync/condvar.rs

rust/kernel/fs.rs specifically FileDescriptorReservation``rust/kernel/fs.rs，特别是 FileDescriptorReservation

rust/kernel/seq_file.rs``rust/内核/seq_file.rs

rust/kernel/uaccess.rs``rust/内核/uaccess.rs

To find these, you can inspect the Rust symbols yourself by building the kernel and running this command:要找到这些，您可以通过构建内核并运行以下命令来自己检查 Rust 符号：
nm vmlinux | grep ' _R' | rustfilt
Examples of good patches that make this kind of change:进行此类更改的良好补丁示例：

Example that fixes rust/kernel/cred.rs修复 rust/kernel/cred.rs 的示例

Example that fixes rust/kernel/security.rs修复 rust/kernel/security.rs 的示例

If you submit a patch that makes this kind of change, please make sure to have a good commit message (see the examples above).如果您提交的补丁进行了此类更改，请确保有一个好的提交消息（请参阅上面的示例）。

This requires submitting a proper patch to the LKML and the Rust for Linux mailing list. Please recall to test your changes (including generating the documentation if changed, running the Rust doctests if changed, etc.), to use a proper title for the commit, to sign your commit under the Developer's Certificate of Origin and to add a Suggested-by: tag and a Link: tag to this issue. Please see https://docs.kernel.org/process/submitting-patches.html and https://rust-for-linux.com/contributing for details.这需要向 LKML 和 Rust for Linux 邮件列表提交适当的补丁。请回想测试您的更改（包括更改后生成文档，如果更改则运行 Rust 文档测试等），为提交使用适当的标题，在开发者的原产地证书下签署您的提交，并为此问题添加 Suggested-by：标签和 Link： 标签。有关详细信息，请参阅 https://docs.kernel.org/process/submitting-patches.html 和 https://rust-for-linux.com/contributing。

Please take this issue only if you are new to the kernel development process and you would like to use it as a test to submit your first patch to the kernel. Please do not take it if you do not plan to make other contributions to the kernel.仅当您不熟悉内核开发过程，并且希望将其用作测试以向内核提交您的第一个补丁时，才请关注此问题。如果您不打算对内核做出其他贡献，请不要接受它。

When writing abstractions around core C apis, we often have Rust functions that do nothing other than call a C function. In those cases, we don't want the generated code to have a trivial Rust wrapper around the C function — Rust should inline it and generate a direct call into C.

However, in some cases that requires an #[inline] marker. Many methods in the kernel is missing it, and so this issue tracks such additions.

A few cases where I know that this is happening:

rust/kernel/task.rs

rust/kernel/page.rs

rust/kernel/sync/condvar.rs

rust/kernel/fs.rs specifically FileDescriptorReservation

rust/kernel/seq_file.rs

rust/kernel/uaccess.rs

To find these, you can inspect the Rust symbols yourself by building the kernel and running this command:
nm vmlinux | grep ' _R' | rustfilt
Examples of good patches that make this kind of change:

Example that fixes rust/kernel/cred.rs

Example that fixes rust/kernel/security.rs

If you submit a patch that makes this kind of change, please make sure to have a good commit message (see the examples above).

This requires submitting a proper patch to the LKML and the Rust for Linux mailing list. Please recall to test your changes (including generating the documentation if changed, running the Rust doctests if changed, etc.), to use a proper title for the commit, to sign your commit under the Developer's Certificate of Origin and to add a Suggested-by: tag and a Link: tag to this issue. Please see https://docs.kernel.org/process/submitting-patches.html and https://rust-for-linux.com/contributing for details.

Please take this issue only if you are new to the kernel development process and you would like to use it as a test to submit your first patch to the kernel. Please do not take it if you do not plan to make other contributions to the kernel.

Thanks for the hint, I'll submit for the unfinished part, allow me to add a Suggested-by tag.

charmitro · 2025-03-11T08:39:14Z

Thanks for the hint, I'll submit for the unfinished part, allow me to add a Suggested-by tag.

Hi @KunWuChan, please note the following regarding issues labeled as "good-first-issue":

Please take this issue only if you are new to the kernel development process and you would like to use it as a test to submit your first patch to the kernel.

When you build the kernel using the llvm-18.1.3-rust-1.85.0-x86_64 toolchain provided by kernel.org, the following symbols are generated: $ nm vmlinux | grep ' _R'.*Task | rustfilt ffffffff817b2d30 T <kernel::task::Task>::get_pid_ns ffffffff817b2d50 T <kernel::task::Task>::tgid_nr_ns ffffffff817b2c90 T <kernel::task::Task>::current_pid_ns ffffffff817b2d00 T <kernel::task::Task>::signal_pending ffffffff817b2cc0 T <kernel::task::Task>::uid ffffffff817b2ce0 T <kernel::task::Task>::euid ffffffff817b2c70 T <kernel::task::Task>::current ffffffff817b2d70 T <kernel::task::Task>::wake_up ffffffff817b2db0 T <kernel::task::Task as kernel::types::AlwaysRefCounted>::dec_ref ffffffff817b2d90 T <kernel::task::Task as kernel::types::AlwaysRefCounted>::inc_ref These Rust symbols are trivial wrappers around the C functions get_pid_ns, task_tgid_nr_ns, task_active_pid_ns, signal_pending, uid, euid, get_current, wake_up, get_task_struct and put_task_struct.It doesn't make sense to go through a trivial wrapper for these functions, so mark them inline. After applying this patch, the above command will produce no output. Link: Rust-for-Linux#1145 Signed-off-by: Panagiotis Foliadis <[email protected]>

KunWuChan · 2025-03-12T07:11:04Z

Hi @KunWuChan, please note the following regarding issues labeled as "good-first-issue":

Please take this issue only if you are new to the kernel development process and you would like to use it as a test to submit your first patch to the kernel.

@charmitro Thanks for the reply. I'm newbie in rust and want do sth for rust.

Currenyly the implementation of "Guard" methods are basically wrappers around rcu's function within kernel. Building the kernel with llvm 18.1.8 on x86_64 machine will generate the following symbols: $ nm vmlinux | grep ' _R'.*Guard | rustfilt ffffffff817b6c90 T <kernel::sync::rcu::Guard>::new ffffffff817b6cb0 T <kernel::sync::rcu::Guard>::unlock ffffffff817b6cd0 T <kernel::sync::rcu::Guard as core::ops::drop::Drop>::drop ffffffff817b6c90 T <kernel::sync::rcu::Guard as core::default::Default>::default These Rust symbols are basically wrappers around functions "rcu_read_lock" and "rcu_read_unlock". Marking them as inline can reduce the generation of these symbols, and saves the size of code generation for 100 bytes. $ ./scripts/bloat-o-meter vmlinux_old vmlinux_new add/remove: 0/8 grow/shrink: 0/0 up/down: 0/-100 (-100) Function old new delta _RNvXs_NtNtCsaYBeKL739Xz_6kernel4sync3rcuNtB4_5GuardNtNtCsdaXADs8PRFB_4core7default7Default7default 9 - -9 _RNvXs0_NtNtCsaYBeKL739Xz_6kernel4sync3rcuNtB5_5GuardNtNtNtCsdaXADs8PRFB_4core3ops4drop4Drop4drop 9 - -9 _RNvMNtNtCsaYBeKL739Xz_6kernel4sync3rcuNtB2_5Guard6unlock 9 - -9 _RNvMNtNtCsaYBeKL739Xz_6kernel4sync3rcuNtB2_5Guard3new 9 - -9 __pfx__RNvXs_NtNtCsaYBeKL739Xz_6kernel4sync3rcuNtB4_5GuardNtNtCsdaXADs8PRFB_4core7default7Default7default 16 - -16 __pfx__RNvXs0_NtNtCsaYBeKL739Xz_6kernel4sync3rcuNtB5_5GuardNtNtNtCsdaXADs8PRFB_4core3ops4drop4Drop4drop 16 - -16 __pfx__RNvMNtNtCsaYBeKL739Xz_6kernel4sync3rcuNtB2_5Guard6unlock 16 - -16 __pfx__RNvMNtNtCsaYBeKL739Xz_6kernel4sync3rcuNtB2_5Guard3new 16 - -16 Total: Before=23385830, After=23385730, chg -0.00% Link: Rust-for-Linux#1145 Signed-off-by: I Hsin Cheng <[email protected]>

When you build the kernel using the llvm-19.1.4-rust-1.83.0-x86_64 toolchain provided by kernel.org with ARCH=x86_64, the following symbol is generated: $nm vmlinux | grep ' _R' | rustfilt | rg UserSliceWriter ffffffff817c3390 T <kernel::uaccess::UserSliceWriter>::write_slice However, this Rust symbol is a trivial wrapper around the function copy_from_user. It doesn't make sense to go through a trivial wrapper for this function, so mark it inline. After applying this patch, the above command will produce no output. Suggested-by: Alice Ryhl <[email protected]> Link: Rust-for-Linux#1145 Signed-off-by: Antonio Hickey <[email protected]>

When you build the kernel using the llvm-19.1.4-rust-1.83.0-x86_64 toolchain provided by kernel.org with ARCH=x86_64, the following symbol is generated: $nm vmlinux | grep ' _R' | rustfilt | rg UserSliceWriter ffffffff817c3390 T <kernel::uaccess::UserSliceWriter>::write_slice However, this Rust symbol is a trivial wrapper around the function copy_to_user. It doesn't make sense to go through a trivial wrapper for this function, so mark it inline. After applying this patch, the above command will produce no output. Suggested-by: Alice Ryhl <[email protected]> Link: Rust-for-Linux#1145 Signed-off-by: Antonio Hickey <[email protected]>

When building the kernel on Arch Linux using on x86_64 with tools: $ rustc --version rustc 1.84.0 (9fc6b4312 2025-01-07) $ clang --version clang version 19.1.7 Target: x86_64-pc-linux-gnu The following symbols are generated: $ nm vmlinux | rg ' _R' | rustfilt | rg faux ffffffff81959ae0 T <kernel::faux::Registration>::new ffffffff81959b40 T <kernel::faux::Registration as core::ops::drop::Drop>::drop However, these Rust symbols are wrappers around bindings in the C faux code. Inlining these functions removes the middle-man wrapper function After applying this patch, the above function signatures disappear. Link: Rust-for-Linux#1145 Signed-off-by: Ethan Carter Edwards <[email protected]> Acked-by: Danilo Krummrich <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Link: https://lore.kernel.org/r/jesg4yu7m6fvzmgg5tlsktrrjm36l4qsranto5mdmnucx4pvf3@nhvt4juw5es3 Signed-off-by: Greg Kroah-Hartman <[email protected]>

When you build the kernel using the llvm-18.1.3-rust-1.85.0-x86_64 toolchain provided by kernel.org, the following symbols are generated: $ nm vmlinux | grep ' _R'.*Task | rustfilt ffffffff817b2d30 T <kernel::task::Task>::get_pid_ns ffffffff817b2d50 T <kernel::task::Task>::tgid_nr_ns ffffffff817b2c90 T <kernel::task::Task>::current_pid_ns ffffffff817b2d00 T <kernel::task::Task>::signal_pending ffffffff817b2cc0 T <kernel::task::Task>::uid ffffffff817b2ce0 T <kernel::task::Task>::euid ffffffff817b2c70 T <kernel::task::Task>::current ffffffff817b2d70 T <kernel::task::Task>::wake_up ffffffff817b2db0 T <kernel::task::Task as kernel::types::AlwaysRefCounted>::dec_ref ffffffff817b2d90 T <kernel::task::Task as kernel::types::AlwaysRefCounted>::inc_ref These Rust symbols are trivial wrappers around the C functions get_pid_ns, task_tgid_nr_ns, task_active_pid_ns, signal_pending, uid, euid, get_current, wake_up, get_task_struct and put_task_struct. It doesn't make sense to go through a trivial wrapper for these functions, so mark them inline. After applying this patch, the above command will produce no output. Link: Rust-for-Linux#1145 Reviewed-by: Benno Lossin <[email protected]> Reviewed-by: Christian Schrefl <[email protected]> Reviewed-by: Charalampos Mitrodimas <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Signed-off-by: Panagiotis Foliadis <[email protected]>

…tion When build the kernel using the llvm-18.1.3-rust-1.85.0-x86_64 with ARCH=arm64, the following symbols are generated: $ nm vmlinux | grep ' _R'.*FileDescriptorReservation | rustfilt ... T <kernel::fs::file::FileDescriptorReservation>::fd_install ... T <kernel::fs::file::FileDescriptorReservation>::get_unused_fd_flags ... T <kernel::fs::file::FileDescriptorReservation as core::ops::drop::Drop>::drop These Rust symbols are trivial wrappers around the C functions fd_install, put_unused_fd and put_task_struct. It doesn't make sense to go through a trivial wrapper for these functions, so mark them inline. Link: Rust-for-Linux#1145 Suggested-by: Alice Ryhl <[email protected]> Co-developed-by: Grace Deng <[email protected]> Signed-off-by: Grace Deng <[email protected]> Signed-off-by: Kunwu Chan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Alice Ryhl <[email protected]> Signed-off-by: Christian Brauner <[email protected]>

When build the kernel using the llvm-18.1.3-rust-1.85.0-x86_64 with ARCH=arm64, the following symbols are generated: $nm vmlinux | grep ' _R'.*SeqFile | rustfilt ffff8000805b78ac T <kernel::seq_file::SeqFile>::call_printf This Rust symbol is trivial wrappers around the C functions seq_printf. It doesn't make sense to go through a trivial wrapper for its functions, so mark it inline. Link: Rust-for-Linux#1145 Suggested-by: Alice Ryhl <[email protected]> Co-developed-by: Grace Deng <[email protected]> Signed-off-by: Grace Deng <[email protected]> Signed-off-by: Kunwu Chan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Signed-off-by: Christian Brauner <[email protected]>

…tion When build the kernel using the llvm-18.1.3-rust-1.85.0-x86_64 with ARCH=arm64, the following symbols are generated: $ nm vmlinux | grep ' _R'.*FileDescriptorReservation | rustfilt ... T <kernel::fs::file::FileDescriptorReservation>::fd_install ... T <kernel::fs::file::FileDescriptorReservation>::get_unused_fd_flags ... T <kernel::fs::file::FileDescriptorReservation as core::ops::drop::Drop>::drop These Rust symbols are trivial wrappers around the C functions fd_install, put_unused_fd and put_task_struct. It doesn't make sense to go through a trivial wrapper for these functions, so mark them inline. Link: Rust-for-Linux#1145 Suggested-by: Alice Ryhl <[email protected]> Co-developed-by: Grace Deng <[email protected]> Signed-off-by: Grace Deng <[email protected]> Signed-off-by: Kunwu Chan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Alice Ryhl <[email protected]> Signed-off-by: Christian Brauner <[email protected]>

When build the kernel using the llvm-18.1.3-rust-1.85.0-x86_64 with ARCH=arm64, the following symbols are generated: $nm vmlinux | grep ' _R'.*SeqFile | rustfilt ffff8000805b78ac T <kernel::seq_file::SeqFile>::call_printf This Rust symbol is trivial wrappers around the C functions seq_printf. It doesn't make sense to go through a trivial wrapper for its functions, so mark it inline. Link: Rust-for-Linux#1145 Suggested-by: Alice Ryhl <[email protected]> Co-developed-by: Grace Deng <[email protected]> Signed-off-by: Grace Deng <[email protected]> Signed-off-by: Kunwu Chan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Signed-off-by: Christian Brauner <[email protected]>

Darksonn added easy Expected to be an easy issue to resolve. good first issue Good for newcomers labels Mar 5, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add missing `#[inline]` markers to trivial wrappers around C functions #1145

Add missing `#[inline]` markers to trivial wrappers around C functions #1145

Darksonn commented Mar 5, 2025 •

edited by ojeda

Loading

panosfol commented Mar 5, 2025

ojeda commented Mar 5, 2025

Darksonn commented Mar 6, 2025

panosfol commented Mar 6, 2025

ethancedwards8 commented Mar 10, 2025

ojeda commented Mar 10, 2025 •

edited

Loading

ethancedwards8 commented Mar 11, 2025

antonio-hickey commented Mar 11, 2025

KunWuChan commented Mar 11, 2025

charmitro commented Mar 11, 2025

KunWuChan commented Mar 12, 2025

Add missing #[inline] markers to trivial wrappers around C functions #1145

Add missing #[inline] markers to trivial wrappers around C functions #1145

Comments

Darksonn commented Mar 5, 2025 • edited by ojeda Loading

panosfol commented Mar 5, 2025

ojeda commented Mar 5, 2025

Darksonn commented Mar 6, 2025

panosfol commented Mar 6, 2025

ethancedwards8 commented Mar 10, 2025

ojeda commented Mar 10, 2025 • edited Loading

ethancedwards8 commented Mar 11, 2025

antonio-hickey commented Mar 11, 2025

KunWuChan commented Mar 11, 2025

charmitro commented Mar 11, 2025

KunWuChan commented Mar 12, 2025

Add missing `#[inline]` markers to trivial wrappers around C functions #1145

Add missing `#[inline]` markers to trivial wrappers around C functions #1145

Darksonn commented Mar 5, 2025 •

edited by ojeda

Loading

ojeda commented Mar 10, 2025 •

edited

Loading