From: Alice Ryhl <aliceryhl@google.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Miguel Ojeda <ojeda@kernel.org>,
a.hindborg@kernel.org, acourbot@nvidia.com,
akpm@linux-foundation.org, anton.ivanov@cambridgegreys.com,
bjorn3_gh@protonmail.com, boqun.feng@gmail.com, dakr@kernel.org,
david@davidgow.net, gary@garyguo.net, johannes@sipsolutions.net,
justinstitt@google.com, linux-arm-kernel@lists.infradead.org,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-um@lists.infradead.org,
llvm@lists.linux.dev, lossin@kernel.org, mark.rutland@arm.com,
mmaurer@google.com, morbo@google.com, nathan@kernel.org,
nick.desaulniers+lkml@gmail.com, nicolas.schier@linux.dev,
nsc@kernel.org, peterz@infradead.org, richard@nod.at,
rust-for-linux@vger.kernel.org, tmgross@umich.edu,
urezki@gmail.com, will@kernel.org
Subject: Re: Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
Date: Thu, 26 Mar 2026 10:10:10 +0000 [thread overview]
Message-ID: <acUGAsjYvNvTEO92@google.com> (raw)
In-Reply-To: <acEP7tl8pqFA3tK8@shell.armlinux.org.uk>
On Mon, Mar 23, 2026 at 10:03:26AM +0000, Russell King (Oracle) wrote:
> On Mon, Mar 23, 2026 at 01:03:27AM +0100, Miguel Ojeda wrote:
> > On Sun, 22 Mar 2026 20:21:59 +0100 Miguel Ojeda <ojeda@kernel.org> wrote:
> > >
> > > On the other hand, regardless of whether we fix this (and another
> > > issue in a separate email found thanks to the UML build), we could
> > > instead add `depends on` listing explicitly the architectures where
> > > this is going to be actually tested. That way maintainers can decide
> > > whether they want to support it when they are ready. Thoughts?
> >
> > Another one for arm 32-bit:
> >
> > LD .tmp_vmlinux1
> > ld.lld: error: undefined symbol: __aeabi_read_tp
> > >>> referenced by uaccess.rs:349 (rust/kernel/uaccess.rs:349)
> > >>> samples/rust/rust_misc_device.o:(<rust_misc_device::RustMiscDevice as kernel::miscdevice::MiscDevice>::ioctl) in archive vmlinux.a
> > >>> referenced by uaccess.rs:543 (rust/kernel/uaccess.rs:543)
> > >>> samples/rust/rust_misc_device.o:(<rust_misc_device::RustMiscDevice as kernel::miscdevice::MiscDevice>::ioctl) in archive vmlinux.a
> > >>> referenced by uaccess.rs:543 (rust/kernel/uaccess.rs:543)
> > >>> drivers/android/binder/rust_binder_main.o:(rust_binder_main::rust_binder_ioctl) in archive vmlinux.a
> > >>> referenced 36 more times
>
> Why is Rust generating code for userspace thread accessors for kernel
> space, where userspace threads are meaningless. This is totally wrong.
> The kernel must not reference __aeabi_read_tp().
>
> Note: I know nothing about Rust, but I know enough to say the above is
> pointing to a fundamental issue in Rust for 32-bit ARM.
I noticed that the Makefile currently uses the arm-unknown-linux-gnueabi
target. It should probably not be -linux target to avoid this? Probably
it should just be armv7a-none-eabi, right? We gate HAVE_RUST on
CPU_32v7, so we should not need to consider the other variants.
Alice
next prev parent reply other threads:[~2026-03-26 10:10 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 11:34 [PATCH v2 0/3] Inline helpers into Rust without full LTO Alice Ryhl
2026-02-03 11:34 ` [PATCH v2 1/3] kbuild: rust: add `CONFIG_RUSTC_CLANG_LLVM_COMPATIBLE` Alice Ryhl
2026-02-03 11:49 ` Will Deacon
2026-02-03 12:02 ` Alice Ryhl
2026-03-05 10:12 ` Nicolas Schier
2026-03-05 10:51 ` Alice Ryhl
2026-03-14 0:26 ` Nathan Chancellor
2026-02-03 11:34 ` [PATCH v2 2/3] rust: helpers: #define __rust_helper Alice Ryhl
2026-03-14 0:28 ` Nathan Chancellor
2026-02-03 11:34 ` [PATCH v2 3/3] build: rust: provide an option to inline C helpers into Rust Alice Ryhl
2026-03-06 17:32 ` Alice Ryhl
2026-03-14 0:40 ` Nathan Chancellor
2026-03-14 11:22 ` Alice Ryhl
2026-03-16 21:34 ` Nathan Chancellor
2026-03-17 8:02 ` Miguel Ojeda
2026-03-14 0:34 ` Nathan Chancellor
2026-03-17 8:25 ` [PATCH v2 0/3] Inline helpers into Rust without full LTO Andreas Hindborg
2026-03-22 19:21 ` Miguel Ojeda
2026-03-22 19:38 ` Miguel Ojeda
2026-03-23 13:54 ` Mark Brown
2026-03-23 14:53 ` Miguel Ojeda
2026-03-22 19:46 ` Miguel Ojeda
2026-03-23 8:49 ` Marek Szyprowski
2026-03-25 1:58 ` Miguel Ojeda
2026-03-26 21:12 ` Arnd Bergmann
2026-03-27 8:02 ` Miguel Ojeda
2026-03-27 8:16 ` Marek Szyprowski
2026-03-23 0:03 ` Miguel Ojeda
2026-03-23 3:04 ` Andrew Lunn
2026-03-23 3:24 ` Miguel Ojeda
2026-03-23 12:54 ` Andrew Lunn
2026-03-23 13:13 ` Gary Guo
2026-03-23 13:28 ` Andrew Lunn
2026-03-23 13:34 ` Miguel Ojeda
2026-03-23 14:39 ` Alice Ryhl
2026-03-23 13:14 ` Miguel Ojeda
2026-03-23 10:03 ` Russell King (Oracle)
2026-03-23 13:26 ` Miguel Ojeda
2026-03-26 10:10 ` Alice Ryhl [this message]
2026-03-26 13:47 ` Miguel Ojeda
2026-03-26 14:31 ` Christian Schrefl
2026-03-26 15:18 ` Russell King (Oracle)
2026-03-26 17:30 ` Miguel Ojeda
2026-03-30 21:09 ` Christian Schrefl
2026-03-31 11:44 ` Arnd Bergmann
2026-03-26 21:33 ` Arnd Bergmann
2026-03-27 7:56 ` Geert Uytterhoeven
2026-03-27 9:02 ` Arnd Bergmann
2026-03-27 13:41 ` Arnd Bergmann
2026-03-30 12:03 ` Geert Uytterhoeven
2026-03-30 12:13 ` Arnd Bergmann
2026-03-30 12:17 ` Geert Uytterhoeven
2026-03-26 17:31 ` Miguel Ojeda
2026-03-26 2:42 ` Nathan Chancellor
2026-03-26 17:13 ` Miguel Ojeda
2026-03-26 5:34 ` David Gow
2026-03-29 17:33 ` Miguel Ojeda
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=acUGAsjYvNvTEO92@google.com \
--to=aliceryhl@google.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=anton.ivanov@cambridgegreys.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=david@davidgow.net \
--cc=gary@garyguo.net \
--cc=johannes@sipsolutions.net \
--cc=justinstitt@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-um@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=llvm@lists.linux.dev \
--cc=lossin@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mmaurer@google.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=nicolas.schier@linux.dev \
--cc=nsc@kernel.org \
--cc=ojeda@kernel.org \
--cc=peterz@infradead.org \
--cc=richard@nod.at \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=urezki@gmail.com \
--cc=will@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.