* [PATCH] rust: alloc: allow different error types in `KBox::pin_slice`
@ 2026-02-14 13:28 Andreas Hindborg
2026-02-14 13:37 ` Andreas Hindborg
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Andreas Hindborg @ 2026-02-14 13:28 UTC (permalink / raw)
To: Danilo Krummrich, Lorenzo Stoakes, Vlastimil Babka,
Liam R. Howlett, Uladzislau Rezki, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Alice Ryhl,
Trevor Gross
Cc: rust-for-linux, linux-kernel, Andreas Hindborg
Previously, `KBox::pin_slice` required the initializer error type to match
the return error type via `E: From<AllocError>`. This prevented using
infallible initializers like `new_mutex!` inside `pin_slice`, because
`Infallible` does not implement `From<AllocError>`.
Introduce a separate type parameter `E2` for the initializer error type and
require `AllocError: Into<E>` and `E2: Into<E>` instead. This allows the
initializer to return a different error type that can be converted into the
final error type, enabling use of infallible pin initializers in fallible
allocation contexts.
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
---
@Benno, I would like to add your SoB and CDB tags.
---
rust/kernel/alloc/kbox.rs | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/rust/kernel/alloc/kbox.rs b/rust/kernel/alloc/kbox.rs
index 622b3529edfcb..8dbc58b988f1c 100644
--- a/rust/kernel/alloc/kbox.rs
+++ b/rust/kernel/alloc/kbox.rs
@@ -323,7 +323,7 @@ pub fn pin(x: T, flags: Flags) -> Result<Pin<Box<T, A>>, AllocError>
/// }
///
/// // Allocate a boxed slice of 10 `Example`s.
- /// let s = KBox::pin_slice(
+ /// let s = KBox::pin_slice::<_, _, Error, _>(
/// | _i | Example::new(),
/// 10,
/// GFP_KERNEL
@@ -333,24 +333,31 @@ pub fn pin(x: T, flags: Flags) -> Result<Pin<Box<T, A>>, AllocError>
/// assert_eq!(s[3].d.lock().a, 20);
/// # Ok::<(), Error>(())
/// ```
- pub fn pin_slice<Func, Item, E>(
+ pub fn pin_slice<Func, Item, E, E2>(
mut init: Func,
len: usize,
flags: Flags,
) -> Result<Pin<Box<[T], A>>, E>
where
Func: FnMut(usize) -> Item,
- Item: PinInit<T, E>,
- E: From<AllocError>,
+ Item: PinInit<T, E2>,
+ AllocError: Into<E>,
+ E2: Into<E>,
{
- let mut buffer = super::Vec::<T, A>::with_capacity(len, flags)?;
+ let mut buffer = match super::Vec::<T, A>::with_capacity(len, flags) {
+ Ok(buffer) => buffer,
+ Err(err) => return Err(err.into()),
+ };
for i in 0..len {
let ptr = buffer.spare_capacity_mut().as_mut_ptr().cast();
// SAFETY:
// - `ptr` is a valid pointer to uninitialized memory.
// - `ptr` is not used if an error is returned.
// - `ptr` won't be moved until it is dropped, i.e. it is pinned.
- unsafe { init(i).__pinned_init(ptr)? };
+ match unsafe { init(i).__pinned_init(ptr) } {
+ Ok(()) => (),
+ Err(err) => return Err(err.into()),
+ }
// SAFETY:
// - `i + 1 <= len`, hence we don't exceed the capacity, due to the call to
---
base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
change-id: 20260214-pin-slice-init-e8ef96fc07b9
Best regards,
--
Andreas Hindborg <a.hindborg@kernel.org>
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH] rust: alloc: allow different error types in `KBox::pin_slice`
2026-02-14 13:28 [PATCH] rust: alloc: allow different error types in `KBox::pin_slice` Andreas Hindborg
@ 2026-02-14 13:37 ` Andreas Hindborg
2026-02-14 14:17 ` Danilo Krummrich
2026-02-14 14:37 ` Benno Lossin
2 siblings, 0 replies; 10+ messages in thread
From: Andreas Hindborg @ 2026-02-14 13:37 UTC (permalink / raw)
To: Danilo Krummrich, Lorenzo Stoakes, Vlastimil Babka,
Liam R. Howlett, Uladzislau Rezki, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Alice Ryhl,
Trevor Gross
Cc: rust-for-linux, linux-kernel
Andreas Hindborg <a.hindborg@kernel.org> writes:
> Previously, `KBox::pin_slice` required the initializer error type to match
> the return error type via `E: From<AllocError>`. This prevented using
> infallible initializers like `new_mutex!` inside `pin_slice`, because
> `Infallible` does not implement `From<AllocError>`.
>
> Introduce a separate type parameter `E2` for the initializer error type and
> require `AllocError: Into<E>` and `E2: Into<E>` instead. This allows the
> initializer to return a different error type that can be converted into the
> final error type, enabling use of infallible pin initializers in fallible
> allocation contexts.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
> ---
> @Benno, I would like to add your SoB and CDB tags.
It just occured to me that we should probably add a zulip Link as well:
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/.E2.9C.94.20Constructing.20Mutex.20from.20PinInit.3CT.2C.20Error.3E/with/567385936
Best regards,
Andreas Hindborg
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] rust: alloc: allow different error types in `KBox::pin_slice`
2026-02-14 13:28 [PATCH] rust: alloc: allow different error types in `KBox::pin_slice` Andreas Hindborg
2026-02-14 13:37 ` Andreas Hindborg
@ 2026-02-14 14:17 ` Danilo Krummrich
2026-02-14 14:40 ` Benno Lossin
2026-02-14 14:37 ` Benno Lossin
2 siblings, 1 reply; 10+ messages in thread
From: Danilo Krummrich @ 2026-02-14 14:17 UTC (permalink / raw)
To: Andreas Hindborg
Cc: Lorenzo Stoakes, Vlastimil Babka, Liam R. Howlett,
Uladzislau Rezki, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Alice Ryhl, Trevor Gross,
rust-for-linux, linux-kernel
On Sat Feb 14, 2026 at 2:28 PM CET, Andreas Hindborg wrote:
> Previously, `KBox::pin_slice` required the initializer error type to match
> the return error type via `E: From<AllocError>`. This prevented using
> infallible initializers like `new_mutex!` inside `pin_slice`, because
> `Infallible` does not implement `From<AllocError>`.
>
> Introduce a separate type parameter `E2` for the initializer error type and
> require `AllocError: Into<E>` and `E2: Into<E>` instead. This allows the
> initializer to return a different error type that can be converted into the
> final error type, enabling use of infallible pin initializers in fallible
> allocation contexts.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
I assume you have a user? I.e. do you need this patch in another tree?
> @@ -333,24 +333,31 @@ pub fn pin(x: T, flags: Flags) -> Result<Pin<Box<T, A>>, AllocError>
> /// assert_eq!(s[3].d.lock().a, 20);
> /// # Ok::<(), Error>(())
> /// ```
> - pub fn pin_slice<Func, Item, E>(
> + pub fn pin_slice<Func, Item, E, E2>(
> mut init: Func,
> len: usize,
> flags: Flags,
> ) -> Result<Pin<Box<[T], A>>, E>
> where
> Func: FnMut(usize) -> Item,
> - Item: PinInit<T, E>,
> - E: From<AllocError>,
I think we should keep this bound and just add:
E: From<E2>,
> + Item: PinInit<T, E2>,
> + AllocError: Into<E>,
> + E2: Into<E>,
> {
> - let mut buffer = super::Vec::<T, A>::with_capacity(len, flags)?;
> + let mut buffer = match super::Vec::<T, A>::with_capacity(len, flags) {
> + Ok(buffer) => buffer,
> + Err(err) => return Err(err.into()),
> + };
This...
> for i in 0..len {
> let ptr = buffer.spare_capacity_mut().as_mut_ptr().cast();
> // SAFETY:
> // - `ptr` is a valid pointer to uninitialized memory.
> // - `ptr` is not used if an error is returned.
> // - `ptr` won't be moved until it is dropped, i.e. it is pinned.
> - unsafe { init(i).__pinned_init(ptr)? };
> + match unsafe { init(i).__pinned_init(ptr) } {
> + Ok(()) => (),
> + Err(err) => return Err(err.into()),
> + }
...and this match becomes unnecessary then.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] rust: alloc: allow different error types in `KBox::pin_slice`
2026-02-14 14:17 ` Danilo Krummrich
@ 2026-02-14 14:40 ` Benno Lossin
2026-02-14 14:56 ` Danilo Krummrich
0 siblings, 1 reply; 10+ messages in thread
From: Benno Lossin @ 2026-02-14 14:40 UTC (permalink / raw)
To: Danilo Krummrich, Andreas Hindborg
Cc: Lorenzo Stoakes, Vlastimil Babka, Liam R. Howlett,
Uladzislau Rezki, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Alice Ryhl, Trevor Gross, rust-for-linux,
linux-kernel
On Sat Feb 14, 2026 at 3:17 PM CET, Danilo Krummrich wrote:
> On Sat Feb 14, 2026 at 2:28 PM CET, Andreas Hindborg wrote:
>> @@ -333,24 +333,31 @@ pub fn pin(x: T, flags: Flags) -> Result<Pin<Box<T, A>>, AllocError>
>> /// assert_eq!(s[3].d.lock().a, 20);
>> /// # Ok::<(), Error>(())
>> /// ```
>> - pub fn pin_slice<Func, Item, E>(
>> + pub fn pin_slice<Func, Item, E, E2>(
>> mut init: Func,
>> len: usize,
>> flags: Flags,
>> ) -> Result<Pin<Box<[T], A>>, E>
>> where
>> Func: FnMut(usize) -> Item,
>> - Item: PinInit<T, E>,
>> - E: From<AllocError>,
>
> I think we should keep this bound and just add:
The `Into` trait bounds are the idiomatic ones for functions consuming
things. See https://doc.rust-lang.org/std/convert/trait.Into.html:
Prefer using Into over From when specifying trait bounds on a
generic function to ensure that types that only implement Into can
be used as well.
I should've said something to Andreas, since he created the commit
message (but this patch has left my L3 cache).
Cheers,
Benno
> E: From<E2>,
>
>> + Item: PinInit<T, E2>,
>> + AllocError: Into<E>,
>> + E2: Into<E>,
>> {
>> - let mut buffer = super::Vec::<T, A>::with_capacity(len, flags)?;
>> + let mut buffer = match super::Vec::<T, A>::with_capacity(len, flags) {
>> + Ok(buffer) => buffer,
>> + Err(err) => return Err(err.into()),
>> + };
>
> This...
>
>> for i in 0..len {
>> let ptr = buffer.spare_capacity_mut().as_mut_ptr().cast();
>> // SAFETY:
>> // - `ptr` is a valid pointer to uninitialized memory.
>> // - `ptr` is not used if an error is returned.
>> // - `ptr` won't be moved until it is dropped, i.e. it is pinned.
>> - unsafe { init(i).__pinned_init(ptr)? };
>> + match unsafe { init(i).__pinned_init(ptr) } {
>> + Ok(()) => (),
>> + Err(err) => return Err(err.into()),
>> + }
>
> ...and this match becomes unnecessary then.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] rust: alloc: allow different error types in `KBox::pin_slice`
2026-02-14 14:40 ` Benno Lossin
@ 2026-02-14 14:56 ` Danilo Krummrich
2026-02-15 23:29 ` Benno Lossin
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Danilo Krummrich @ 2026-02-14 14:56 UTC (permalink / raw)
To: Benno Lossin
Cc: Andreas Hindborg, Lorenzo Stoakes, Vlastimil Babka,
Liam R. Howlett, Uladzislau Rezki, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Alice Ryhl, Trevor Gross,
rust-for-linux, linux-kernel
On Sat Feb 14, 2026 at 3:40 PM CET, Benno Lossin wrote:
> On Sat Feb 14, 2026 at 3:17 PM CET, Danilo Krummrich wrote:
>> On Sat Feb 14, 2026 at 2:28 PM CET, Andreas Hindborg wrote:
>>> @@ -333,24 +333,31 @@ pub fn pin(x: T, flags: Flags) -> Result<Pin<Box<T, A>>, AllocError>
>>> /// assert_eq!(s[3].d.lock().a, 20);
>>> /// # Ok::<(), Error>(())
>>> /// ```
>>> - pub fn pin_slice<Func, Item, E>(
>>> + pub fn pin_slice<Func, Item, E, E2>(
>>> mut init: Func,
>>> len: usize,
>>> flags: Flags,
>>> ) -> Result<Pin<Box<[T], A>>, E>
>>> where
>>> Func: FnMut(usize) -> Item,
>>> - Item: PinInit<T, E>,
>>> - E: From<AllocError>,
>>
>> I think we should keep this bound and just add:
>
> The `Into` trait bounds are the idiomatic ones for functions consuming
> things. See https://doc.rust-lang.org/std/convert/trait.Into.html:
>
> Prefer using Into over From when specifying trait bounds on a
> generic function to ensure that types that only implement Into can
> be used as well.
Yeah, but isn't this only because of [1], which does not apply to the kernel
because our minimum compiler version is 1.78 anyways?
I.e. are there any cases where we can't implement From in the kernel and have to
fall back to Into?
[1] https://doc.rust-lang.org/std/convert/trait.Into.html#implementing-into-for-conversions-to-external-types-in-old-versions-of-rust
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] rust: alloc: allow different error types in `KBox::pin_slice`
2026-02-14 14:56 ` Danilo Krummrich
@ 2026-02-15 23:29 ` Benno Lossin
2026-02-16 8:48 ` Alice Ryhl
2026-02-27 14:38 ` Gary Guo
2 siblings, 0 replies; 10+ messages in thread
From: Benno Lossin @ 2026-02-15 23:29 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Andreas Hindborg, Lorenzo Stoakes, Vlastimil Babka,
Liam R. Howlett, Uladzislau Rezki, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Alice Ryhl, Trevor Gross,
rust-for-linux, linux-kernel
On Sat Feb 14, 2026 at 3:56 PM CET, Danilo Krummrich wrote:
> On Sat Feb 14, 2026 at 3:40 PM CET, Benno Lossin wrote:
>> On Sat Feb 14, 2026 at 3:17 PM CET, Danilo Krummrich wrote:
>>> On Sat Feb 14, 2026 at 2:28 PM CET, Andreas Hindborg wrote:
>>>> @@ -333,24 +333,31 @@ pub fn pin(x: T, flags: Flags) -> Result<Pin<Box<T, A>>, AllocError>
>>>> /// assert_eq!(s[3].d.lock().a, 20);
>>>> /// # Ok::<(), Error>(())
>>>> /// ```
>>>> - pub fn pin_slice<Func, Item, E>(
>>>> + pub fn pin_slice<Func, Item, E, E2>(
>>>> mut init: Func,
>>>> len: usize,
>>>> flags: Flags,
>>>> ) -> Result<Pin<Box<[T], A>>, E>
>>>> where
>>>> Func: FnMut(usize) -> Item,
>>>> - Item: PinInit<T, E>,
>>>> - E: From<AllocError>,
>>>
>>> I think we should keep this bound and just add:
>>
>> The `Into` trait bounds are the idiomatic ones for functions consuming
>> things. See https://doc.rust-lang.org/std/convert/trait.Into.html:
>>
>> Prefer using Into over From when specifying trait bounds on a
>> generic function to ensure that types that only implement Into can
>> be used as well.
>
> Yeah, but isn't this only because of [1], which does not apply to the kernel
> because our minimum compiler version is 1.78 anyways?
>
> I.e. are there any cases where we can't implement From in the kernel and have to
> fall back to Into?
Hmm that's interesting. I'm not sure if that's the only reason. It would
be interesting to ask the Rust folks if there 1) is a different use-case
for `Into` today; and 2) if they could remove `Into`, would they? If the
answer to 2 is "yes", then we could think about doing that (or at least
document it for us).
Cheers,
Benno
>
> [1] https://doc.rust-lang.org/std/convert/trait.Into.html#implementing-into-for-conversions-to-external-types-in-old-versions-of-rust
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] rust: alloc: allow different error types in `KBox::pin_slice`
2026-02-14 14:56 ` Danilo Krummrich
2026-02-15 23:29 ` Benno Lossin
@ 2026-02-16 8:48 ` Alice Ryhl
2026-02-16 9:37 ` Danilo Krummrich
2026-02-27 14:38 ` Gary Guo
2 siblings, 1 reply; 10+ messages in thread
From: Alice Ryhl @ 2026-02-16 8:48 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Benno Lossin, Andreas Hindborg, Lorenzo Stoakes, Vlastimil Babka,
Liam R. Howlett, Uladzislau Rezki, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Trevor Gross, rust-for-linux,
linux-kernel
On Sat, Feb 14, 2026 at 03:56:43PM +0100, Danilo Krummrich wrote:
> On Sat Feb 14, 2026 at 3:40 PM CET, Benno Lossin wrote:
> > On Sat Feb 14, 2026 at 3:17 PM CET, Danilo Krummrich wrote:
> >> On Sat Feb 14, 2026 at 2:28 PM CET, Andreas Hindborg wrote:
> >>> @@ -333,24 +333,31 @@ pub fn pin(x: T, flags: Flags) -> Result<Pin<Box<T, A>>, AllocError>
> >>> /// assert_eq!(s[3].d.lock().a, 20);
> >>> /// # Ok::<(), Error>(())
> >>> /// ```
> >>> - pub fn pin_slice<Func, Item, E>(
> >>> + pub fn pin_slice<Func, Item, E, E2>(
> >>> mut init: Func,
> >>> len: usize,
> >>> flags: Flags,
> >>> ) -> Result<Pin<Box<[T], A>>, E>
> >>> where
> >>> Func: FnMut(usize) -> Item,
> >>> - Item: PinInit<T, E>,
> >>> - E: From<AllocError>,
> >>
> >> I think we should keep this bound and just add:
> >
> > The `Into` trait bounds are the idiomatic ones for functions consuming
> > things. See https://doc.rust-lang.org/std/convert/trait.Into.html:
> >
> > Prefer using Into over From when specifying trait bounds on a
> > generic function to ensure that types that only implement Into can
> > be used as well.
>
> Yeah, but isn't this only because of [1], which does not apply to the kernel
> because our minimum compiler version is 1.78 anyways?
>
> I.e. are there any cases where we can't implement From in the kernel and have to
> fall back to Into?
Probably not, but it's still best practice to use Into over From when
specifying trait bounds.
Alice
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] rust: alloc: allow different error types in `KBox::pin_slice`
2026-02-16 8:48 ` Alice Ryhl
@ 2026-02-16 9:37 ` Danilo Krummrich
0 siblings, 0 replies; 10+ messages in thread
From: Danilo Krummrich @ 2026-02-16 9:37 UTC (permalink / raw)
To: Alice Ryhl
Cc: Benno Lossin, Andreas Hindborg, Lorenzo Stoakes, Vlastimil Babka,
Liam R. Howlett, Uladzislau Rezki, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Trevor Gross, rust-for-linux,
linux-kernel
On Mon Feb 16, 2026 at 9:48 AM CET, Alice Ryhl wrote:
> On Sat, Feb 14, 2026 at 03:56:43PM +0100, Danilo Krummrich wrote:
>> Yeah, but isn't this only because of [1], which does not apply to the kernel
>> because our minimum compiler version is 1.78 anyways?
>>
>> I.e. are there any cases where we can't implement From in the kernel and have to
>> fall back to Into?
>
> Probably not, but it's still best practice to use Into over From when
> specifying trait bounds.
I'm aware; my point is that I'm questioning this best practice in the context of
a modern and self-contained project like Rust in the kernel.
This patch is a very good example, as there seem to be zero downsides to a From
trait bound, while using the From trait bound allows for cleaner code.
(I.e. we get rid of the matches and can use the '?' operator instead. To be
fair, this could also be written as `.map_err(Into::into)?`, but still.)
I'd even argue that using a From trait bound here is a feature and not a
limitation. I.e. if someone would pass something that implements Into (but not
From) we'd catch it and can tell the caller to implement From instead of Into,
which is preferred and should always be possible in the kernel.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] rust: alloc: allow different error types in `KBox::pin_slice`
2026-02-14 14:56 ` Danilo Krummrich
2026-02-15 23:29 ` Benno Lossin
2026-02-16 8:48 ` Alice Ryhl
@ 2026-02-27 14:38 ` Gary Guo
2 siblings, 0 replies; 10+ messages in thread
From: Gary Guo @ 2026-02-27 14:38 UTC (permalink / raw)
To: Danilo Krummrich, Benno Lossin
Cc: Andreas Hindborg, Lorenzo Stoakes, Vlastimil Babka,
Liam R. Howlett, Uladzislau Rezki, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Alice Ryhl, Trevor Gross,
rust-for-linux, linux-kernel
On Sat Feb 14, 2026 at 2:56 PM GMT, Danilo Krummrich wrote:
> On Sat Feb 14, 2026 at 3:40 PM CET, Benno Lossin wrote:
>> On Sat Feb 14, 2026 at 3:17 PM CET, Danilo Krummrich wrote:
>>> On Sat Feb 14, 2026 at 2:28 PM CET, Andreas Hindborg wrote:
>>>> @@ -333,24 +333,31 @@ pub fn pin(x: T, flags: Flags) -> Result<Pin<Box<T, A>>, AllocError>
>>>> /// assert_eq!(s[3].d.lock().a, 20);
>>>> /// # Ok::<(), Error>(())
>>>> /// ```
>>>> - pub fn pin_slice<Func, Item, E>(
>>>> + pub fn pin_slice<Func, Item, E, E2>(
>>>> mut init: Func,
>>>> len: usize,
>>>> flags: Flags,
>>>> ) -> Result<Pin<Box<[T], A>>, E>
>>>> where
>>>> Func: FnMut(usize) -> Item,
>>>> - Item: PinInit<T, E>,
>>>> - E: From<AllocError>,
>>>
>>> I think we should keep this bound and just add:
>>
>> The `Into` trait bounds are the idiomatic ones for functions consuming
>> things. See https://doc.rust-lang.org/std/convert/trait.Into.html:
>>
>> Prefer using Into over From when specifying trait bounds on a
>> generic function to ensure that types that only implement Into can
>> be used as well.
>
> Yeah, but isn't this only because of [1], which does not apply to the kernel
> because our minimum compiler version is 1.78 anyways?
>
> I.e. are there any cases where we can't implement From in the kernel and have to
> fall back to Into?
>
> [1] https://doc.rust-lang.org/std/convert/trait.Into.html#implementing-into-for-conversions-to-external-types-in-old-versions-of-rust
There's one benefit in using `From` in trait bound -- you can call both `From::from`
and `Into::into` inside the function. If you only have `Into` bound, then
`From::from` is not callable. A very minor benefit, though.
Another interesting observation is that `?` operator (i.e. impl of the unstable
`FromResidual` trait on `Result`) uses `From` instead of `Into`. I cannot find a
reason why this is done this way, though.
Best,
Gary
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] rust: alloc: allow different error types in `KBox::pin_slice`
2026-02-14 13:28 [PATCH] rust: alloc: allow different error types in `KBox::pin_slice` Andreas Hindborg
2026-02-14 13:37 ` Andreas Hindborg
2026-02-14 14:17 ` Danilo Krummrich
@ 2026-02-14 14:37 ` Benno Lossin
2 siblings, 0 replies; 10+ messages in thread
From: Benno Lossin @ 2026-02-14 14:37 UTC (permalink / raw)
To: Andreas Hindborg, Danilo Krummrich, Lorenzo Stoakes,
Vlastimil Babka, Liam R. Howlett, Uladzislau Rezki, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Alice Ryhl,
Trevor Gross
Cc: rust-for-linux, linux-kernel
On Sat Feb 14, 2026 at 2:28 PM CET, Andreas Hindborg wrote:
> Previously, `KBox::pin_slice` required the initializer error type to match
> the return error type via `E: From<AllocError>`. This prevented using
> infallible initializers like `new_mutex!` inside `pin_slice`, because
> `Infallible` does not implement `From<AllocError>`.
>
> Introduce a separate type parameter `E2` for the initializer error type and
> require `AllocError: Into<E>` and `E2: Into<E>` instead. This allows the
> initializer to return a different error type that can be converted into the
> final error type, enabling use of infallible pin initializers in fallible
> allocation contexts.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
> ---
> @Benno, I would like to add your SoB and CDB tags.
Please do.
Cheers,
Benno
> ---
> rust/kernel/alloc/kbox.rs | 19 +++++++++++++------
> 1 file changed, 13 insertions(+), 6 deletions(-)
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2026-02-27 14:38 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-14 13:28 [PATCH] rust: alloc: allow different error types in `KBox::pin_slice` Andreas Hindborg
2026-02-14 13:37 ` Andreas Hindborg
2026-02-14 14:17 ` Danilo Krummrich
2026-02-14 14:40 ` Benno Lossin
2026-02-14 14:56 ` Danilo Krummrich
2026-02-15 23:29 ` Benno Lossin
2026-02-16 8:48 ` Alice Ryhl
2026-02-16 9:37 ` Danilo Krummrich
2026-02-27 14:38 ` Gary Guo
2026-02-14 14:37 ` Benno Lossin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox