[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D8IMV6MH4EVX.3BWHLLY5UGLC0@proton.me>
Date: Mon, 17 Mar 2025 15:06:51 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Antonio Hickey <contact@...oniohickey.com>
Cc: a.hindborg@...nel.org, alex.gaynor@...il.com, aliceryhl@...gle.com, bjorn3_gh@...tonmail.com, boqun.feng@...il.com, dakr@...nel.org, gary@...yguo.net, justinstitt@...gle.com, linux-kernel@...r.kernel.org, llvm@...ts.linux.dev, morbo@...gle.com, nathan@...nel.org, nick.desaulniers+lkml@...il.com, ojeda@...nel.org, rust-for-linux@...r.kernel.org, tmgross@...ch.edu
Subject: Re: [PATCH v2] rust: uaccess: mark UserSliceWriter method inline
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@...gle.com>
>> > Link: https://github.com/Rust-for-Linux/linux/issues/1145
>> > Signed-off-by: Antonio Hickey <contact@...oniohickey.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
Powered by blists - more mailing lists