[PATCH] rust: xarray: optimize lock functions with inline attribute

[PATCH] rust: xarray: optimize lock functions with inline attribute

[lingfuyi]

From: lingfuyi <lingfuyi@kylinos.cn>

The XArray lock and try_lock functions are simple wrappers around
the C functions xa_lock and xa_trylock. These Rust functions don't
add significant logic beyond the unsafe FFI calls and safety guarantees.

Mark them as inline to avoid unnecessary function call overhead in
hot paths where XArray locking is frequent, such as in page cache
operations and other kernel data structure management.

This follows the same optimization pattern as other Rust kernel
modules where simple C function wrappers are marked inline to
improve performance.

Signed-off-by: lingfuyi <lingfuyi@kylinos.cn>
---
 rust/kernel/xarray.rs | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/rust/kernel/xarray.rs b/rust/kernel/xarray.rs
index a49d6db28845..c96589f92927 100644
--- a/rust/kernel/xarray.rs
+++ b/rust/kernel/xarray.rs
@@ -119,6 +119,7 @@ fn iter(&self) -> impl Iterator<Item = NonNull<c_void>> + '_ {
     }
 
     /// Attempts to lock the [`XArray`] for exclusive access.
+    #[inline]
     pub fn try_lock(&self) -> Option<Guard<'_, T>> {
         // SAFETY: `self.xa` is always valid by the type invariant.
         if (unsafe { bindings::xa_trylock(self.xa.get()) } != 0) {
@@ -132,6 +133,7 @@ pub fn try_lock(&self) -> Option<Guard<'_, T>> {
     }
 
     /// Locks the [`XArray`] for exclusive access.
+    #[inline]
     pub fn lock(&self) -> Guard<'_, T> {
         // SAFETY: `self.xa` is always valid by the type invariant.
         unsafe { bindings::xa_lock(self.xa.get()) };
-- 
2.34.1

Re: [PATCH] rust: xarray: optimize lock functions with inline attribute

[Elle Rhumsaa]

On Mon, Aug 18, 2025 at 01:16:12AM +0000, lingfuyi@126.com wrote:
> From: lingfuyi <lingfuyi@kylinos.cn>
> 
> The XArray lock and try_lock functions are simple wrappers around
> the C functions xa_lock and xa_trylock. These Rust functions don't
> add significant logic beyond the unsafe FFI calls and safety guarantees.
> 
> Mark them as inline to avoid unnecessary function call overhead in
> hot paths where XArray locking is frequent, such as in page cache
> operations and other kernel data structure management.
> 
> This follows the same optimization pattern as other Rust kernel
> modules where simple C function wrappers are marked inline to
> improve performance.
> 
> Signed-off-by: lingfuyi <lingfuyi@kylinos.cn>
> ---
>  rust/kernel/xarray.rs | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/rust/kernel/xarray.rs b/rust/kernel/xarray.rs
> index a49d6db28845..c96589f92927 100644
> --- a/rust/kernel/xarray.rs
> +++ b/rust/kernel/xarray.rs
> @@ -119,6 +119,7 @@ fn iter(&self) -> impl Iterator<Item = NonNull<c_void>> + '_ {
>      }
>  
>      /// Attempts to lock the [`XArray`] for exclusive access.
> +    #[inline]
>      pub fn try_lock(&self) -> Option<Guard<'_, T>> {
>          // SAFETY: `self.xa` is always valid by the type invariant.
>          if (unsafe { bindings::xa_trylock(self.xa.get()) } != 0) {
> @@ -132,6 +133,7 @@ pub fn try_lock(&self) -> Option<Guard<'_, T>> {
>      }
>  
>      /// Locks the [`XArray`] for exclusive access.
> +    #[inline]
>      pub fn lock(&self) -> Guard<'_, T> {
>          // SAFETY: `self.xa` is always valid by the type invariant.
>          unsafe { bindings::xa_lock(self.xa.get()) };
> -- 
> 2.34.1

Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev>

[PATCH] rust: xarray: optimize lock functions with inline attribute

[lingfuyi]

From: lingfuyi <lingfuyi@kylinos.cn>

The XArray lock and try_lock functions are simple wrappers around
the C functions xa_lock and xa_trylock. These Rust functions don't
add significant logic beyond the unsafe FFI calls and safety guarantees.

Mark them as inline to avoid unnecessary function call overhead in
hot paths where XArray locking is frequent, such as in page cache
operations and other kernel data structure management.

This follows the same optimization pattern as other Rust kernel
modules where simple C function wrappers are marked inline to
improve performance.

Signed-off-by: lingfuyi <lingfuyi@kylinos.cn>
---
 rust/kernel/xarray.rs | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/rust/kernel/xarray.rs b/rust/kernel/xarray.rs
index a49d6db28845..c96589f92927 100644
--- a/rust/kernel/xarray.rs
+++ b/rust/kernel/xarray.rs
@@ -119,6 +119,7 @@ fn iter(&self) -> impl Iterator<Item = NonNull<c_void>> + '_ {
     }
 
     /// Attempts to lock the [`XArray`] for exclusive access.
+    #[inline]
     pub fn try_lock(&self) -> Option<Guard<'_, T>> {
         // SAFETY: `self.xa` is always valid by the type invariant.
         if (unsafe { bindings::xa_trylock(self.xa.get()) } != 0) {
@@ -132,6 +133,7 @@ pub fn try_lock(&self) -> Option<Guard<'_, T>> {
     }
 
     /// Locks the [`XArray`] for exclusive access.
+    #[inline]
     pub fn lock(&self) -> Guard<'_, T> {
         // SAFETY: `self.xa` is always valid by the type invariant.
         unsafe { bindings::xa_lock(self.xa.get()) };
-- 
2.34.1

Re: [PATCH] rust: xarray: optimize lock functions with inline attribute

[Alice Ryhl]

On Mon, Aug 18, 2025 at 3:27 AM <lingfuyi@126.com> wrote:
>
> From: lingfuyi <lingfuyi@kylinos.cn>
>
> The XArray lock and try_lock functions are simple wrappers around
> the C functions xa_lock and xa_trylock. These Rust functions don't
> add significant logic beyond the unsafe FFI calls and safety guarantees.
>
> Mark them as inline to avoid unnecessary function call overhead in
> hot paths where XArray locking is frequent, such as in page cache
> operations and other kernel data structure management.
>
> This follows the same optimization pattern as other Rust kernel
> modules where simple C function wrappers are marked inline to
> improve performance.
>
> Signed-off-by: lingfuyi <lingfuyi@kylinos.cn>

Thanks for the patch. Please see the Developer’s Certificate of Origin 1.1
https://docs.kernel.org/process/submitting-patches.html#developer-s-certificate-of-origin-1-1

You need to use a known identity such as your real name to submit
patches to the kernel. Anonymous contributions aren't possible.

Also please include a version number in the email subject when sending
a new version of a patch.

Alice

Re: [PATCH] rust: xarray: optimize lock functions with inline attribute

[Miguel Ojeda]

On Mon, Aug 18, 2025 at 3:27 AM <lingfuyi@126.com> wrote:
>
> Signed-off-by: lingfuyi <lingfuyi@kylinos.cn>

The kernel requires using a "known identity" (typically meaning the
full/real name) -- please see
https://docs.kernel.org/process/submitting-patches.html#developer-s-certificate-of-origin-1-1

Also, please do not resend patches with the same title -- you should
increase the version number if you do so (or, in this case, if you
just wanted to Cc people, you can do that replying to the patch,
saying who you are Cc'ing).

Cheers,
Miguel

Re: [PATCH] rust: xarray: optimize lock functions with inline attribute

[Miguel Ojeda]

On Mon, Aug 18, 2025 at 10:05 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> The kernel requires using a "known identity" (typically meaning the
> full/real name) -- please see
> https://docs.kernel.org/process/submitting-patches.html#developer-s-certificate-of-origin-1-1
>
> Also, please do not resend patches with the same title -- you should
> increase the version number if you do so (or, in this case, if you
> just wanted to Cc people, you can do that replying to the patch,
> saying who you are Cc'ing).

By the way, the From header, generally, should match that too
(otherwise the "From" line gets added in the body, here because you
use a different domain).

Thanks!

Cheers,
Miguel

[PATCH] rust: xarray: optimize lock functions with inline attribute

[凌福义]

[-- Attachment #1: Type: text/html, Size: 1697 bytes --]

Re: [PATCH] rust: xarray: optimize lock functions with inline attribute

[Greg KH]

On Sat, Aug 16, 2025 at 05:45:01PM +0800, 凌福义 wrote:
> The XArray lock and try_lock functions are simple wrappers around
> the C functions xa_lock and xa_trylock. These Rust functions don't
> add significant logic beyond the unsafe FFI calls and safety guarantees.
> 
> Mark them as inline to avoid unnecessary function call overhead in
> hot paths where XArray locking is frequent, such as in page cache
> operations and other kernel data structure management.
> 
> This follows the same optimization pattern as other Rust kernel
> modules where simple C function wrappers are marked inline to
> improve performance.
> 
> Signed-off-by: lingfuyi <lingfuyi@kylinos.cn>
> ---
> rust/kernel/xarray.rs | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/rust/kernel/xarray.rs b/rust/kernel/xarray.rs
> index a49d6db28845..c96589f92927 100644
> --- a/rust/kernel/xarray.rs
> +++ b/rust/kernel/xarray.rs
> @@ -119,6 +119,7 @@ fn iter(&self) -> impl Iterator<Item = NonNull<c_void>> +
> '_ {
> }
> 
> /// Attempts to lock the [`XArray`] for exclusive access.
> + #[inline]
> pub fn try_lock(&self) -> Option<Guard<'_, T>> {
> // SAFETY: `self.xa` is always valid by the type invariant.
> if (unsafe { bindings::xa_trylock(self.xa.get()) } != 0) {
> @@ -132,6 +133,7 @@ pub fn try_lock(&self) -> Option<Guard<'_, T>> {
> }
> 
> /// Locks the [`XArray`] for exclusive access.
> + #[inline]
> pub fn lock(&self) -> Guard<'_, T> {
> // SAFETY: `self.xa` is always valid by the type invariant.
> unsafe { bindings::xa_lock(self.xa.get()) };
> --
> 2.34.1
> 
> 
> 
> 
> 
> 
> ----
> 
>  
> 


Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch is malformed (tabs converted to spaces, linewrapped, etc.)
  and can not be applied.  Please read the file,
  Documentation/process/email-clients.rst in order to fix this.


If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot