Add const_align_up() to kernel::ptr as the const-compatible equivalent
of Alignable::align_up().

Suggested-by: Danilo Krummrich <dakr@kernel.org>
Suggested-by: Gary Guo <gary@garyguo.net>
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
 rust/kernel/ptr.rs | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/rust/kernel/ptr.rs b/rust/kernel/ptr.rs
index bdc2d79ff669..7e99f129543b 100644
--- a/rust/kernel/ptr.rs
+++ b/rust/kernel/ptr.rs
@@ -253,3 +253,27 @@ fn size(p: *const Self) -> usize {
         p.len() * size_of::<T>()
     }
 }
+
+/// Aligns `value` up to `align`.
+///
+/// This is the const-compatible equivalent of [`Alignable::align_up`].
+///
+/// Returns [`None`] on overflow.
+///
+/// # Examples
+///
+/// ```
+/// use kernel::ptr::{const_align_up, Alignment};
+/// use kernel::sizes::SZ_4K;
+///
+/// assert_eq!(const_align_up(0x4f, Alignment::new::<16>()), Some(0x50));
+/// assert_eq!(const_align_up(0x40, Alignment::new::<16>()), Some(0x40));
+/// assert_eq!(const_align_up(1, Alignment::new::<SZ_4K>()), Some(SZ_4K));
+/// ```
+#[inline(always)]
+pub const fn const_align_up(value: usize, align: Alignment) -> Option<usize> {
+    match value.checked_add(align.as_usize() - 1) {
+        Some(v) => Some(v & align.mask()),
+        None => None,
+    }
+}
-- 
2.53.0

On Thu Mar 26, 2026 at 10:38 AM JST, John Hubbard wrote:
> Add const_align_up() to kernel::ptr as the const-compatible equivalent
> of Alignable::align_up().
>
> Suggested-by: Danilo Krummrich <dakr@kernel.org>
> Suggested-by: Gary Guo <gary@garyguo.net>
> Suggested-by: Miguel Ojeda <ojeda@kernel.org>
> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
> Reviewed-by: Gary Guo <gary@garyguo.net>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---
>  rust/kernel/ptr.rs | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
>
> diff --git a/rust/kernel/ptr.rs b/rust/kernel/ptr.rs
> index bdc2d79ff669..7e99f129543b 100644
> --- a/rust/kernel/ptr.rs
> +++ b/rust/kernel/ptr.rs
> @@ -253,3 +253,27 @@ fn size(p: *const Self) -> usize {
>          p.len() * size_of::<T>()
>      }
>  }
> +
> +/// Aligns `value` up to `align`.
> +///
> +/// This is the const-compatible equivalent of [`Alignable::align_up`].
> +///
> +/// Returns [`None`] on overflow.
> +///
> +/// # Examples
> +///
> +/// ```
> +/// use kernel::ptr::{const_align_up, Alignment};

IIUC we use the one-import-per-line style (minus the unneeded `//`) in
examples as well (I suppose this can be fixed when applying).

Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>

On 3/30/26 7:21 PM, Alexandre Courbot wrote:
> On Thu Mar 26, 2026 at 10:38 AM JST, John Hubbard wrote:
...
>> +/// Aligns `value` up to `align`.
>> +///
>> +/// This is the const-compatible equivalent of [`Alignable::align_up`].
>> +///
>> +/// Returns [`None`] on overflow.
>> +///
>> +/// # Examples
>> +///
>> +/// ```
>> +/// use kernel::ptr::{const_align_up, Alignment};
> 
> IIUC we use the one-import-per-line style (minus the unneeded `//`) in
> examples as well (I suppose this can be fixed when applying).
> 

Actually no, it's the opposite! Rust for Linux code overwhelmingly
(I counted ~200 cases) prefers the "put it all in one line" style,
in examples.

In fact, I did both grep and AI-powered searches, and failed to find
even a single example of the one-import-per-line style in doc comment
examples.


> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>

Thanks for the review!

thanks,
-- 
John Hubbard

On Tue, Mar 31, 2026 at 4:36 AM John Hubbard <jhubbard@nvidia.com> wrote:
>
> Actually no, it's the opposite! Rust for Linux code overwhelmingly
> (I counted ~200 cases) prefers the "put it all in one line" style,
> in examples.
>
> In fact, I did both grep and AI-powered searches, and failed to find
> even a single example of the one-import-per-line style in doc comment
> examples.

Yeah, it is because it is not decided -- Andreas, for instance, had a
case a month ago where there were many imports for a particular
example, so it would take a lot of lines (if not hidden) and, in
principle, merge conflicts shouldn't be an issue that often there:

  https://lore.kernel.org/rust-for-linux/87ikbn2x4n.fsf@t14s.mail-host-address-is-not-set/

On the other hand, consistency is good (and simpler to not to remember
different rules depending on the context etc.).

Thoughts/feedback on the matter would be nice to have -- thanks!

Cheers,
Miguel

On 3/31/26 12:24 PM, Miguel Ojeda wrote:
> Thoughts/feedback on the matter would be nice to have -- thanks!
For the stuff I maintain I generally tell people to follow the kernel import
style in examples as well. Especially when the imports are part of the example,
as it would be teaching people the wrong thing otherwise.

I.e. it would be a bit odd if an example illustrates the wrong thing.

If they are hidden it depends a bit, and for some cases, like the one you
mentioned, it might make sense to keep it concise.

But in the case of this patch the imports are part of the example (i.e. not
hidden), so they should follow the usual kernel rules.

On Thu, Mar 26, 2026 at 2:39 AM John Hubbard <jhubbard@nvidia.com> wrote:
>
> Add const_align_up() to kernel::ptr as the const-compatible equivalent
> of Alignable::align_up().
>
> Suggested-by: Danilo Krummrich <dakr@kernel.org>
> Suggested-by: Gary Guo <gary@garyguo.net>
> Suggested-by: Miguel Ojeda <ojeda@kernel.org>
> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
> Reviewed-by: Gary Guo <gary@garyguo.net>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>

Acked-by: Miguel Ojeda <ojeda@kernel.org>

Cheers,
Miguel

On 3/27/26 2:33 AM, Miguel Ojeda wrote:
> On Thu, Mar 26, 2026 at 2:39 AM John Hubbard <jhubbard@nvidia.com> wrote:
>>
>> Add const_align_up() to kernel::ptr as the const-compatible equivalent
>> of Alignable::align_up().
>>
>> Suggested-by: Danilo Krummrich <dakr@kernel.org>
>> Suggested-by: Gary Guo <gary@garyguo.net>
>> Suggested-by: Miguel Ojeda <ojeda@kernel.org>
>> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
>> Reviewed-by: Gary Guo <gary@garyguo.net>
>> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> 
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
> 

I probably should ask this out loud, just to be sure: is this
patch on track to get merged though one of the various rust-*
repositories? Or more to the point, is there anything I can
do to help here?


thanks,
-- 
John Hubbard

On Mon, Mar 30, 2026 at 11:41 PM John Hubbard <jhubbard@nvidia.com> wrote:
>
> I probably should ask this out loud, just to be sure: is this
> patch on track to get merged though one of the various rust-*
> repositories? Or more to the point, is there anything I can
> do to help here?

Since it is in a series that uses it in later patches, the usual
assumption is that it is meant to land together. That is why I
provided the Acked-by, i.e. so that it can be merged elsewhere.

But if you want me to pick it up this cycle instead (e.g. perhaps
because you don't intend to land the series this cycle and you would
prefer to have one less patch to worry about), then I am happy to do
that too, yeah.

(Sometimes we avoid that if the users are unlikely to land etc., i.e.
the usual no dead code rule, but this series seems like it will land
and the patch contains a general enough tool.)

Up to you!

I hope that clarifies.

Cheers,
Miguel

On Tue Mar 31, 2026 at 9:03 AM JST, Miguel Ojeda wrote:
> On Mon, Mar 30, 2026 at 11:41 PM John Hubbard <jhubbard@nvidia.com> wrote:
>>
>> I probably should ask this out loud, just to be sure: is this
>> patch on track to get merged though one of the various rust-*
>> repositories? Or more to the point, is there anything I can
>> do to help here?
>
> Since it is in a series that uses it in later patches, the usual
> assumption is that it is meant to land together. That is why I
> provided the Acked-by, i.e. so that it can be merged elsewhere.
>
> But if you want me to pick it up this cycle instead (e.g. perhaps
> because you don't intend to land the series this cycle and you would
> prefer to have one less patch to worry about), then I am happy to do
> that too, yeah.
>
> (Sometimes we avoid that if the users are unlikely to land etc., i.e.
> the usual no dead code rule, but this series seems like it will land
> and the patch contains a general enough tool.)

The series won't land this cycle (but is the priority for the next one),
and this patch is clearly an outlier as it belongs in the kernel crate,
so it looks like a good candidate for you to pick if you don't mind the
temporary dead code. Aligning constants up is a common operation that is
worth making available early IMHO. :)

On Tue, Mar 31, 2026 at 4:23 AM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> The series won't land this cycle (but is the priority for the next one),
> and this patch is clearly an outlier as it belongs in the kernel crate,
> so it looks like a good candidate for you to pick if you don't mind the
> temporary dead code. Aligning constants up is a common operation that is
> worth making available early IMHO. :)

Sounds good!

Cheers,
Miguel