All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Gary Guo" <gary@garyguo.net>, "Alexandre Courbot" <acourbot@nvidia.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.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>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Viresh Kumar" <viresh.kumar@linaro.org>,
	"Will Deacon" <will@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v3 3/7] rust: cpufreq: always inline functions using build_assert with arguments
Date: Tue, 09 Dec 2025 09:52:13 +0900	[thread overview]
Message-ID: <DET9WD6T0KR4.1MILPHIC2LIWB@nvidia.com> (raw)
In-Reply-To: <20251208135521.5d1dd7f6.gary@garyguo.net>

On Mon Dec 8, 2025 at 10:55 PM JST, Gary Guo wrote:
> On Mon, 08 Dec 2025 11:47:01 +0900
> Alexandre Courbot <acourbot@nvidia.com> wrote:
>
>> `build_assert` relies on the compiler to optimize out its error path.
>> Functions using it with its arguments must thus always be inlined,
>> otherwise the error path of `build_assert` might not be optimized out,
>> triggering a build error.
>> 
>> Cc: stable@vger.kernel.org
>> Fixes: c6af9a1191d0 ("rust: cpufreq: Extend abstractions for driver registration")
>> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>>  rust/kernel/cpufreq.rs | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/rust/kernel/cpufreq.rs b/rust/kernel/cpufreq.rs
>> index f968fbd22890..0879a79485f8 100644
>> --- a/rust/kernel/cpufreq.rs
>> +++ b/rust/kernel/cpufreq.rs
>> @@ -1015,6 +1015,8 @@ impl<T: Driver> Registration<T> {
>>          ..pin_init::zeroed()
>>      };
>>  
>> +    // Always inline to optimize out error path of `build_assert`.
>> +    #[inline(always)]
>>      const fn copy_name(name: &'static CStr) -> [c_char; CPUFREQ_NAME_LEN] {
>>          let src = name.to_bytes_with_nul();
>>          let mut dst = [0; CPUFREQ_NAME_LEN];
>> 
>
> This change is not needed as this is a private function only used in
> const-eval only.

... for now. :)

>
> I wonder if I should add another macro to assert that the function is
> only used in const eval instead? Do you think it might be useful to have
> something like:
>
> 	#[const_only]
> 	const fn foo() {}
>
> or
>
> 	const fn foo() {
> 	    const_only!();
> 	}
>
> ? If so, I can send a patch that adds this feature. 
>
> Implementation-wise, this will behave similar to build_error, where a
> function is going to be added that is never-linked but has a body for
> const eval.

It could be useful in the general sense, but for this particular case
the rule "if you do build_assert on a function argument, then always
inline it" also covers us in case `copy_name` gets used outside of const
context, so isn't it the preferable workaround?

  reply	other threads:[~2025-12-09  0:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-08  2:46 [PATCH v3 0/7] rust: build_assert: document and fix use with function arguments Alexandre Courbot
2025-12-08  2:46 ` [PATCH v3 1/7] rust: build_assert: add instructions for " Alexandre Courbot
2025-12-08  2:47 ` [PATCH v3 2/7] rust: io: always inline functions using build_assert with arguments Alexandre Courbot
2026-01-14 19:26   ` Timur Tabi
2025-12-08  2:47 ` [PATCH v3 3/7] rust: cpufreq: " Alexandre Courbot
2025-12-08 13:55   ` Gary Guo
2025-12-09  0:52     ` Alexandre Courbot [this message]
2025-12-09 12:02       ` Gary Guo
2025-12-09  1:01     ` Miguel Ojeda
2025-12-15  5:06     ` Viresh Kumar
2025-12-15 11:14       ` Gary Guo
2025-12-16  6:48         ` Viresh Kumar
2025-12-08  2:47 ` [PATCH v3 4/7] rust: bits: " Alexandre Courbot
2025-12-08  2:47 ` [PATCH v3 5/7] rust: sync: refcount: " Alexandre Courbot
2026-01-15  7:49   ` Miguel Ojeda
2026-01-15  8:40     ` Boqun Feng
2025-12-08  2:47 ` [PATCH v3 6/7] rust: irq: " Alexandre Courbot
2025-12-08  2:47 ` [PATCH v3 7/7] rust: num: bounded: add missing comment for always inlined function Alexandre Courbot
2025-12-08 13:49 ` [PATCH v3 0/7] rust: build_assert: document and fix use with function arguments Gary Guo
2025-12-09  0:54   ` Alexandre Courbot
2026-01-14 19:37 ` Danilo Krummrich
2026-01-18 19:45 ` Miguel Ojeda
2026-01-19  8:19 ` 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=DET9WD6T0KR4.1MILPHIC2LIWB@nvidia.com \
    --to=acourbot@nvidia.com \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=ojeda@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tmgross@umich.edu \
    --cc=viresh.kumar@linaro.org \
    --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.