Add a method to consume a `Box<T, A>` and return a `NonNull<T>`. This
is a convenience wrapper around `Self::into_raw` for callers that need
a `NonNull` pointer rather than a raw pointer.

Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
---
 rust/kernel/alloc/kbox.rs | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/rust/kernel/alloc/kbox.rs b/rust/kernel/alloc/kbox.rs
index 622b3529edfcb..e6efdd572aeea 100644
--- a/rust/kernel/alloc/kbox.rs
+++ b/rust/kernel/alloc/kbox.rs
@@ -213,6 +213,14 @@ pub fn leak<'a>(b: Self) -> &'a mut T {
         // which points to an initialized instance of `T`.
         unsafe { &mut *Box::into_raw(b) }
     }
+
+    /// Consumes the `Box<T,A>` and returns a `NonNull<T>`.
+    ///
+    /// Like [`Self::into_raw`], but returns a `NonNull`.
+    pub fn into_nonnull(b: Self) -> NonNull<T> {
+        // SAFETY: `KBox::into_raw` returns a valid pointer.
+        unsafe { NonNull::new_unchecked(Self::into_raw(b)) }
+    }
 }
 
 impl<T, A> Box<MaybeUninit<T>, A>

-- 
2.51.2

On Tue Feb 24, 2026 at 11:17 AM GMT, Andreas Hindborg wrote:
> Add a method to consume a `Box<T, A>` and return a `NonNull<T>`. This
> is a convenience wrapper around `Self::into_raw` for callers that need
> a `NonNull` pointer rather than a raw pointer.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
> ---
>  rust/kernel/alloc/kbox.rs | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/rust/kernel/alloc/kbox.rs b/rust/kernel/alloc/kbox.rs
> index 622b3529edfcb..e6efdd572aeea 100644
> --- a/rust/kernel/alloc/kbox.rs
> +++ b/rust/kernel/alloc/kbox.rs
> @@ -213,6 +213,14 @@ pub fn leak<'a>(b: Self) -> &'a mut T {
>          // which points to an initialized instance of `T`.
>          unsafe { &mut *Box::into_raw(b) }
>      }
> +
> +    /// Consumes the `Box<T,A>` and returns a `NonNull<T>`.
> +    ///
> +    /// Like [`Self::into_raw`], but returns a `NonNull`.
> +    pub fn into_nonnull(b: Self) -> NonNull<T> {
> +        // SAFETY: `KBox::into_raw` returns a valid pointer.
> +        unsafe { NonNull::new_unchecked(Self::into_raw(b)) }
> +    }

Hi Andreas,

It looks like this patch and many others in the series are missing `#[inline]`
for quite a few very simple functions. Could you go through the series and mark
small functions as such?

Thanks,
Gary

>  }
>  
>  impl<T, A> Box<MaybeUninit<T>, A>

"Gary Guo" <gary@garyguo.net> writes:

> On Tue Feb 24, 2026 at 11:17 AM GMT, Andreas Hindborg wrote:
>> Add a method to consume a `Box<T, A>` and return a `NonNull<T>`. This
>> is a convenience wrapper around `Self::into_raw` for callers that need
>> a `NonNull` pointer rather than a raw pointer.
>>
>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>> ---
>>  rust/kernel/alloc/kbox.rs | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/rust/kernel/alloc/kbox.rs b/rust/kernel/alloc/kbox.rs
>> index 622b3529edfcb..e6efdd572aeea 100644
>> --- a/rust/kernel/alloc/kbox.rs
>> +++ b/rust/kernel/alloc/kbox.rs
>> @@ -213,6 +213,14 @@ pub fn leak<'a>(b: Self) -> &'a mut T {
>>          // which points to an initialized instance of `T`.
>>          unsafe { &mut *Box::into_raw(b) }
>>      }
>> +
>> +    /// Consumes the `Box<T,A>` and returns a `NonNull<T>`.
>> +    ///
>> +    /// Like [`Self::into_raw`], but returns a `NonNull`.
>> +    pub fn into_nonnull(b: Self) -> NonNull<T> {
>> +        // SAFETY: `KBox::into_raw` returns a valid pointer.
>> +        unsafe { NonNull::new_unchecked(Self::into_raw(b)) }
>> +    }
>
> Hi Andreas,
>
> It looks like this patch and many others in the series are missing `#[inline]`
> for quite a few very simple functions. Could you go through the series and mark
> small functions as such?

Sure.

Could you remind me why we need this directive? Would the compiler not
be able to decide?

I know we have an issue when we have call to C function in short
functions, but not in the general case?


Best regards,
Andreas Hindborg

On Sun Mar 1, 2026 at 4:34 PM GMT, Andreas Hindborg wrote:
> "Gary Guo" <gary@garyguo.net> writes:
>
>> On Tue Feb 24, 2026 at 11:17 AM GMT, Andreas Hindborg wrote:
>>> Add a method to consume a `Box<T, A>` and return a `NonNull<T>`. This
>>> is a convenience wrapper around `Self::into_raw` for callers that need
>>> a `NonNull` pointer rather than a raw pointer.
>>>
>>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>>> ---
>>>  rust/kernel/alloc/kbox.rs | 8 ++++++++
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/rust/kernel/alloc/kbox.rs b/rust/kernel/alloc/kbox.rs
>>> index 622b3529edfcb..e6efdd572aeea 100644
>>> --- a/rust/kernel/alloc/kbox.rs
>>> +++ b/rust/kernel/alloc/kbox.rs
>>> @@ -213,6 +213,14 @@ pub fn leak<'a>(b: Self) -> &'a mut T {
>>>          // which points to an initialized instance of `T`.
>>>          unsafe { &mut *Box::into_raw(b) }
>>>      }
>>> +
>>> +    /// Consumes the `Box<T,A>` and returns a `NonNull<T>`.
>>> +    ///
>>> +    /// Like [`Self::into_raw`], but returns a `NonNull`.
>>> +    pub fn into_nonnull(b: Self) -> NonNull<T> {
>>> +        // SAFETY: `KBox::into_raw` returns a valid pointer.
>>> +        unsafe { NonNull::new_unchecked(Self::into_raw(b)) }
>>> +    }
>>
>> Hi Andreas,
>>
>> It looks like this patch and many others in the series are missing `#[inline]`
>> for quite a few very simple functions. Could you go through the series and mark
>> small functions as such?
>
> Sure.
>
> Could you remind me why we need this directive? Would the compiler not
> be able to decide?

`#[inline]` is a hint to make it more likely for compilers to inline. Without
them, you're relying on compiler heurstics only. There're cases (especially with
abstractions) where the function may look complex as it contains lots of
function calls (so compiler heurstics avoid inlining them), but they're all
zero-cost abstractions so eventually things get optimized away.

For non-generic functions, there is additional issue where only very small
functions get automatically inlined, otherwise a single copy is generated at the
defining crate and compiler run on a dependant crate has no chance to even peek
what's in the function.

If you know a function should be inlined, it's better to just mark them as such,
so there're no surprises.

Best,
Gary

>
> I know we have an issue when we have call to C function in short
> functions, but not in the general case?
>
>
> Best regards,
> Andreas Hindborg

On Sun Mar 1, 2026 at 8:25 PM CET, Gary Guo wrote:
> `#[inline]` is a hint to make it more likely for compilers to inline. Without
> them, you're relying on compiler heurstics only. There're cases (especially with
> abstractions) where the function may look complex as it contains lots of
> function calls (so compiler heurstics avoid inlining them), but they're all
> zero-cost abstractions so eventually things get optimized away.
>
> For non-generic functions, there is additional issue where only very small
> functions get automatically inlined, otherwise a single copy is generated at the
> defining crate and compiler run on a dependant crate has no chance to even peek
> what's in the function.
>
> If you know a function should be inlined, it's better to just mark them as such,
> so there're no surprises.

Should we set clippy::missing_inline_in_public_items [1] to "warn"?

[1]: https://rust-lang.github.io/rust-clippy/master/index.html?search=missing_inline_in_public_items

Cheers,
Benno

On Sun Mar 1, 2026 at 7:59 PM GMT, Benno Lossin wrote:
> On Sun Mar 1, 2026 at 8:25 PM CET, Gary Guo wrote:
>> `#[inline]` is a hint to make it more likely for compilers to inline. Without
>> them, you're relying on compiler heurstics only. There're cases (especially with
>> abstractions) where the function may look complex as it contains lots of
>> function calls (so compiler heurstics avoid inlining them), but they're all
>> zero-cost abstractions so eventually things get optimized away.
>>
>> For non-generic functions, there is additional issue where only very small
>> functions get automatically inlined, otherwise a single copy is generated at the
>> defining crate and compiler run on a dependant crate has no chance to even peek
>> what's in the function.
>>
>> If you know a function should be inlined, it's better to just mark them as such,
>> so there're no surprises.
>
> Should we set clippy::missing_inline_in_public_items [1] to "warn"?
>
> [1]: https://rust-lang.github.io/rust-clippy/master/index.html?search=missing_inline_in_public_items

That requires *all* public items to be `#[inline]` regardless the size, which is
excessive.

Best,
Gary

>
> Cheers,
> Benno

"Gary Guo" <gary@garyguo.net> writes:

> On Sun Mar 1, 2026 at 7:59 PM GMT, Benno Lossin wrote:
>> On Sun Mar 1, 2026 at 8:25 PM CET, Gary Guo wrote:
>>> `#[inline]` is a hint to make it more likely for compilers to inline. Without
>>> them, you're relying on compiler heurstics only. There're cases (especially with
>>> abstractions) where the function may look complex as it contains lots of
>>> function calls (so compiler heurstics avoid inlining them), but they're all
>>> zero-cost abstractions so eventually things get optimized away.
>>>
>>> For non-generic functions, there is additional issue where only very small
>>> functions get automatically inlined, otherwise a single copy is generated at the
>>> defining crate and compiler run on a dependant crate has no chance to even peek
>>> what's in the function.
>>>
>>> If you know a function should be inlined, it's better to just mark them as such,
>>> so there're no surprises.
>>
>> Should we set clippy::missing_inline_in_public_items [1] to "warn"?
>>
>> [1]: https://rust-lang.github.io/rust-clippy/master/index.html?search=missing_inline_in_public_items
>
> That requires *all* public items to be `#[inline]` regardless the size, which is
> excessive.

I was thinking something similar, in clippy or checkpatch.pl. If we
should always have this attribute for small functions, we need to have a
check.


Best regards,
Andreas Hindborg

On Mon, Mar 2, 2026 at 8:19 AM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>
> I was thinking something similar, in clippy or checkpatch.pl. If we
> should always have this attribute for small functions, we need to have a
> check.

No, as Gary said, we do not always want to have it.

So something trivial in `checkpatch.pl` or something like the existing
Clippy lint would have quite bad false positives (and even false
negatives, in the case of `checkpatch.pl`, depending on what logic you
are thinking about).

We would need cross-TU heuristics for this, because at the end of the
day what you are trying to say is "this function will end up being
trivial even if it may look like it doesn't before inlining
everything".

Cheers,
Miguel