From: Miguel Ojeda <ojeda@kernel.org>
To: Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
Daniel Almeida <daniel.almeida@collabora.com>,
Jean Delvare <khali@linux-fr.org>,
ojeda@kernel.org
Cc: linux-kernel@vger.kernel.org, a.hindborg@kernel.org,
acourbot@nvidia.com, akpm@linux-foundation.org,
aliceryhl@google.com, 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-mm@kvack.org,
linux-um@lists.infradead.org, linux@armlinux.org.uk,
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: Sun, 22 Mar 2026 20:38:30 +0100 [thread overview]
Message-ID: <20260322193830.89324-1-ojeda@kernel.org> (raw)
In-Reply-To: <20260322192159.88138-1-ojeda@kernel.org>
On Sun, 22 Mar 2026 20:21:59 +0100 Miguel Ojeda <ojeda@kernel.org> wrote:
>
> I will reply to a couple other bindings in separate emails to avoid
> spamming people too much.
In a series of tests, in some cases, I noticed an `objtool` warning for
x86_64:
rust/kernel.o: warning: objtool: _R..._9RegulatorNtB5_8DisabledE3get() is missing an ELF size annotation
rust/kernel.o: warning: objtool: _R..._9RegulatorNtB5_7EnabledE3get() is missing an ELF size annotation
I noticed that it only happened when `CONFIG_REGULATOR` was disabled. It
seems that we have undefined behavior in `regulator.rs`...
We have `Regulator<Enabled/Disabled>::get()` which calls
`get_internal()` which calls the `regulator_get()` helper, which returns
`NULL` when `CONFIG_REGULATOR` is not set. Then the return value is
passed to `from_err_ptr` which checks `IS_ERR`, which returns false
(unlike `IS_ERR_OR_NULL`), and thus we return an `Ok(NULL)`, which we
then pass to `NonNull::new_unchecked`:
// SAFETY: We can safely trust `inner` to be a pointer to a valid
// regulator if `ERR_PTR` was not returned.
let inner = unsafe { NonNull::new_unchecked(inner) };
So we should fix that -- it is there since its introduction in commit
9b614ceada7c ("rust: regulator: add a bare minimum regulator
abstraction"). How to fix that depends on whether the Rust abstraction
supposed to work transparently like the C API, I assume.
Now, two improvements I think we should independently do too:
- The docs on `regulator_get()` don't say it may return `NULL`. It
originally that case, but commit be1a50d4eba4 ("regulator: Let
drivers know when they use the stub API") changed that without
changing the docs.
I mean, the "docs" are on the real function, but still, one may look
into those and not realize the stub does something different.
The implementation comment on the stub is also a bit contradictory.
The original sentence (which still is there) says that nothing
should look at the value, but then it goes onto say that drivers may
actually look at the value.
- On the Rust general infrastructure side, we should document more
prominently that `from_err_ptr` may return `Ok(NULL)` just fine,
since it calls `IS_ERR`. It may be obvious, since `NULL` is not an
error value, but still, it could have perhaps prevented this issue.
We should also include an example to the doctest showing and testing
that particular case to drive the point home.
I can add that as a "good first issue".
Cc'ing Liam, Mark, Daniel, Jean.
I hope that helps.
Cheers,
Miguel
next prev parent reply other threads:[~2026-03-22 19:40 UTC|newest]
Thread overview: 46+ 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 [this message]
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-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
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-26 21:33 ` Arnd Bergmann
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
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=20260322193830.89324-1-ojeda@kernel.org \
--to=ojeda@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=aliceryhl@google.com \
--cc=anton.ivanov@cambridgegreys.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=broonie@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=david@davidgow.net \
--cc=gary@garyguo.net \
--cc=johannes@sipsolutions.net \
--cc=justinstitt@google.com \
--cc=khali@linux-fr.org \
--cc=lgirdwood@gmail.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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox