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 <aliceryhl@google.com>
Link: https://github.com/Rust-for-Linux/linux/issues/1145
Signed-off-by: Antonio Hickey <contact@antoniohickey.com>
---
 rust/kernel/uaccess.rs | 1 +
 1 file changed, 1 insertion(+)

diff --git a/rust/kernel/uaccess.rs b/rust/kernel/uaccess.rs
index 719b0a48ff55..c33ff33d4da2 100644
--- a/rust/kernel/uaccess.rs
+++ b/rust/kernel/uaccess.rs
@@ -322,6 +322,7 @@ pub fn is_empty(&self) -> bool {
     /// Fails with [`EFAULT`] if the write happens on a bad address, or if the write goes out of
     /// bounds of this [`UserSliceWriter`]. This call may modify the associated userspace slice even
     /// if it returns an error.
+    #[inline]
     pub fn write_slice(&mut self, data: &[u8]) -> Result {
         let len = data.len();
         let data_ptr = data.as_ptr().cast::<c_void>();
-- 
2.48.1

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 <aliceryhl@google.com>
Link: https://github.com/Rust-for-Linux/linux/issues/1145
Signed-off-by: Antonio Hickey <contact@antoniohickey.com>
---
 rust/kernel/uaccess.rs | 1 +
 1 file changed, 1 insertion(+)

diff --git a/rust/kernel/uaccess.rs b/rust/kernel/uaccess.rs
index 719b0a48ff55..c33ff33d4da2 100644
--- a/rust/kernel/uaccess.rs
+++ b/rust/kernel/uaccess.rs
@@ -322,6 +322,7 @@ pub fn is_empty(&self) -> bool {
     /// Fails with [`EFAULT`] if the write happens on a bad address, or if the write goes out of
     /// bounds of this [`UserSliceWriter`]. This call may modify the associated userspace slice even
     /// if it returns an error.
+    #[inline]
     pub fn write_slice(&mut self, data: &[u8]) -> Result {
         let len = data.len();
         let data_ptr = data.as_ptr().cast::<c_void>();
-- 
2.48.1

On Thu Mar 13, 2025 at 3:57 AM CET, Antonio Hickey wrote:
> 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 <aliceryhl@google.com>
> Link: https://github.com/Rust-for-Linux/linux/issues/1145
> Signed-off-by: Antonio Hickey <contact@antoniohickey.com>

What about the other methods (like `write` and `read`?) in this file?

---
Cheers,
Benno

On Sun, Mar 16, 2025 at 05:47:40PM +0000, Benno Lossin wrote:
> On Thu Mar 13, 2025 at 3:57 AM CET, Antonio Hickey wrote:
> > 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 <aliceryhl@google.com>
> > Link: https://github.com/Rust-for-Linux/linux/issues/1145
> > Signed-off-by: Antonio Hickey <contact@antoniohickey.com>
> 
> What about the other methods (like `write` and `read`?) in this file?

Hey Benno,

The other methods in this file were handled with the patch
linked below. This was one of my first patches, so I was
unaware of patch sets and did 2 seperate patches.

Link to other patch: https://lore.kernel.org/all/010001958798b97c-4da7647e-d0bc-4f81-9132-ad24353139cb-000000@email.amazonses.com/

Do you think it would be best to send these as new patch which
includes both of these patches? also if so would it be ok to
start that new patch set at v1 ?

Sorry for the confusion I'm new to kernel dev and patches,
but starting to get the hang of it now.

Thanks,
Antonio

> 
> ---
> Cheers,
> Benno
>

On Sun Mar 16, 2025 at 7:54 PM CET, Antonio Hickey wrote:
> On Sun, Mar 16, 2025 at 05:47:40PM +0000, Benno Lossin wrote:
>> On Thu Mar 13, 2025 at 3:57 AM CET, Antonio Hickey wrote:
>> > 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 <aliceryhl@google.com>
>> > Link: https://github.com/Rust-for-Linux/linux/issues/1145
>> > Signed-off-by: Antonio Hickey <contact@antoniohickey.com>
>> 
>> What about the other methods (like `write` and `read`?) in this file?
>
> Hey Benno,
>
> The other methods in this file were handled with the patch
> linked below. This was one of my first patches, so I was
> unaware of patch sets and did 2 seperate patches.
>
> Link to other patch: https://lore.kernel.org/all/010001958798b97c-4da7647e-d0bc-4f81-9132-ad24353139cb-000000@email.amazonses.com/

Ah I see.

> Do you think it would be best to send these as new patch which
> includes both of these patches? also if so would it be ok to
> start that new patch set at v1 ?

I don't 100% know what to do here, maybe Miguel can help. Personally,
I'd think that another v1 is confusing, but I have seen people in the
past add patches to their already existing series (while incrementing
the version number). I think it's a good idea to merge the patches into
a single one that handles the entire file though.

> Sorry for the confusion I'm new to kernel dev and patches,
> but starting to get the hang of it now.

No worries.

---
Cheers,
Benno

On Mon, Mar 17, 2025 at 4:07 PM Benno Lossin <benno.lossin@proton.me> wrote:
>
> I don't 100% know what to do here, maybe Miguel can help. Personally,
> I'd think that another v1 is confusing, but I have seen people in the
> past add patches to their already existing series (while incrementing
> the version number). I think it's a good idea to merge the patches into
> a single one that handles the entire file though.

I would say that what is most important is to mention what was done,
i.e. linking to the previous thread(s) and saying it was merged or not
so that it is clear what is being done.

If this is just `UserSliceWriter` and `UserSliceReader`, then yeah, a
single patch seems good enough. It is not a fix, which could require
different `Fixes:` tags or things like that.

Thanks!

Cheers,
Miguel