From: Alice Ryhl <aliceryhl@google.com>
To: "Yury Norov (NVIDIA)" <yury.norov@gmail.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Arnd Bergmann" <arnd@arndb.de>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"John Hubbard" <jhubbard@nvidia.com>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v2] uaccess: decouple INLINE_COPY_FROM_USER and CONFIG_RUST
Date: Tue, 18 Nov 2025 10:39:56 +0000 [thread overview]
Message-ID: <aRxM_NHhekMl9joH@google.com> (raw)
In-Reply-To: <20251024154754.99768-1-yury.norov@gmail.com>
On Fri, Oct 24, 2025 at 11:47:53AM -0400, Yury Norov (NVIDIA) wrote:
> Commit 1f9a8286bc0c ("uaccess: always export _copy_[from|to]_user with
> CONFIG_RUST") exports _copy_{from,to}_user() unconditionally, if RUST
> is enabled. This pollutes exported symbols namespace, and spreads RUST
> ifdefery in core files.
>
> It's better to declare a corresponding helper under the rust/helpers,
> similarly to how non-underscored copy_{from,to}_user() is handled.
>
> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
> Tested-by: Alice Ryhl <aliceryhl@google.com>
> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
It looks like this is not quite correct. The header file still has this
declaration unconditionally:
extern __must_check unsigned long
_copy_from_user(void *, const void __user *, unsigned long);
extern __must_check unsigned long
_copy_to_user(void __user *, const void *, unsigned long);
this causes:
ERROR: modpost: "_copy_from_user" [samples/rust/rust_misc_device.ko] undefined!
ERROR: modpost: "_copy_to_user" [samples/rust/rust_misc_device.ko] undefined!
This is because when Rust sees both a helper and a non-helper of the
same function, it prefers to call the non-helper version. In this case,
it saw a declaration of the function in the header file, and so it tried
to call that instead of the helper.
To fix this, we need to wrap the above declarations in:
#ifndef INLINE_COPY_FROM_USER
Alice
next prev parent reply other threads:[~2025-11-18 10:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 15:47 [PATCH v2] uaccess: decouple INLINE_COPY_FROM_USER and CONFIG_RUST Yury Norov (NVIDIA)
2025-10-24 16:16 ` Arnd Bergmann
2025-10-24 17:39 ` Miguel Ojeda
2025-11-18 10:39 ` Alice Ryhl [this message]
2025-11-18 17:18 ` Andrew Morton
2025-11-18 17:32 ` [PATCH] uaccess: gate _copy_[to|from]_user on !INLINE_COPY_FROM_USER Alice Ryhl
2025-11-18 17:40 ` Alice Ryhl
2025-11-18 19:51 ` [PATCH v2] uaccess: decouple INLINE_COPY_FROM_USER and CONFIG_RUST Yury Norov
2025-11-18 20:39 ` Alice Ryhl
2025-11-19 0:08 ` Philip Li
2025-11-19 0:07 ` Philip Li
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=aRxM_NHhekMl9joH@google.com \
--to=aliceryhl@google.com \
--cc=a.hindborg@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex.gaynor@gmail.com \
--cc=arnd@arndb.de \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=yury.norov@gmail.com \
/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).