Re: [PATCH v5 21/38] rust: ptr: add const_align_up() and enable inline_const feature

[John Hubbard]

On 2/23/26 6:20 AM, Danilo Krummrich wrote:
> On Mon Feb 23, 2026 at 3:16 PM CET, Gary Guo wrote:
>> On 2026-02-23 11:07, Danilo Krummrich wrote:
>>> On Sun Feb 22, 2026 at 8:04 PM CET, John Hubbard wrote:
>>>> On 2/21/26 11:46 PM, Gary Guo wrote:
>>>>> On 2026-02-21 02:09, John Hubbard wrote:
>>>>>> Add const_align_up<ALIGN>() to kernel::ptr as the const-compatible
>>>>>> equivalent of Alignable::align_up(). This uses inline_const to validate
>>>>>> the alignment at compile time with a clear error message.
>>>>>>
>>>> ...
>>>>
>>>>>> +#[inline(always)]
>>>>>> +pub const fn const_align_up<const ALIGN: usize>(value: usize) -> usize {
>>>>>> +    const { assert!(ALIGN.is_power_of_two(), "ALIGN must be a power of two") };
>>>>>> +    match value.checked_add(ALIGN - 1) {
>>>>>> +        Some(v) => v & !(ALIGN - 1),
>>>>>> +        None => panic!("const_align_up: overflow"),
>>>>>
>>>>> This is wrong. Either this function is always used in const context, in which case
>>>>> you take `ALIGN` as normal function parameter and use `build_assert` and `build_error`,
>>>>> or this function can be called from runtime and you shouldn't have a panic call here.
>>>
>>> I think the most common case is that ALIGN is const, but value is not.
>>>
>>> What about keeping the function as is (with the panic() replaced with a Result)
>>> and also add
>>>
>>> 	#[inline(always)]
>>> 	pub const fn const_expect<T: Copy>(opt: Result<T>, &'static str) -> T {
>>> 	    match opt {
>>> 	        Ok(v) => v,
>>> 	        Err(_) => panic!(""),
>>> 	    }
>>> 	}
>>>
>>
>> We already have `Alignable::align_up` for non-const cases, so this would only be used
>> in const context and I don't see the need of having explicit const_expect?
> 
> Fair enough -- unfortunate we can't call this from const context.

OK, so after the dust settled on this discussion, I *think* we ended up
at this, which I have staged for an upcoming v6. Did I understand you both
correctly?

commit 1360a440272976df697140361537c5b697d602e0
Author: John Hubbard <jhubbard@xxxxxxxxxx>
Date:   Thu Feb 19 14:44:02 2026 -0800

    rust: ptr: add const_align_up()
    
    Add const_align_up<ALIGN>() to kernel::ptr as the const-compatible
    equivalent of Alignable::align_up(). This uses inline_const to validate
    the alignment at compile time with a clear error message.
    
    Overflow causes a panic, which becomes a compile-time error in const
    context. For runtime alignment with fallible overflow handling, callers
    should use Alignable::align_up() instead.
    
    Suggested-by: Danilo Krummrich <dakr@xxxxxxxxxx>
    Suggested-by: Miguel Ojeda <ojeda@xxxxxxxxxx>
    Signed-off-by: John Hubbard <jhubbard@xxxxxxxxxx>

diff --git a/rust/kernel/ptr.rs b/rust/kernel/ptr.rs
index 5b6a382637fe..b8b0cb1e0b6b 100644
--- a/rust/kernel/ptr.rs
+++ b/rust/kernel/ptr.rs
@@ -225,3 +225,31 @@ fn align_up(self, alignment: Alignment) -> Option<Self> {
 }
 
 impl_alignable_uint!(u8, u16, u32, u64, usize);
+
+/// Aligns `value` up to `ALIGN` at compile time.
+///
+/// This is the const-compatible equivalent of [`Alignable::align_up`].
+/// `ALIGN` must be a power of two (enforced at compile time).
+///
+/// Panics on overflow, which becomes a compile-time error in const context.
+/// For runtime alignment with fallible overflow handling, use
+/// [`Alignable::align_up`] instead.
+///
+/// # Examples
+///
+/// ```
+/// use kernel::ptr::const_align_up;
+/// use kernel::sizes::SZ_4K;
+///
+/// assert_eq!(const_align_up::<16>(0x4f), 0x50);
+/// assert_eq!(const_align_up::<16>(0x40), 0x40);
+/// assert_eq!(const_align_up::<SZ_4K>(1), SZ_4K);
+/// ```
+#[inline(always)]
+pub const fn const_align_up<const ALIGN: usize>(value: usize) -> usize {
+    const { assert!(ALIGN.is_power_of_two(), "ALIGN must be a power of two") };
+    match value.checked_add(ALIGN - 1) {
+        Some(v) => v & !(ALIGN - 1),
+        None => panic!("const_align_up: overflow"),
+    }
+}
<blueforge> linux-github (nova-core-blackwell-v6)$ 


thanks,
-- 
John Hubbard