Re: [PATCH v5 2/4] slab: Introduce kmalloc_obj() and family

[John Hubbard <jhubbard@nvidia.com>]

On 11/24/25 5:09 PM, Matthew Wilcox wrote:
> On Mon, Nov 24, 2025 at 03:30:19PM -0800, Linus Torvalds wrote:
...
>> Imagine how many other places you add integers to 'unsigned long'.
>> EVERY SINGLE ONE of those places involves sign-extending the integer
>> and then doing arithmetic in unsigned.
> 
> I have bad news.  Rust requires it.

Well, yes.

But the pain is front-loaded, so it's not like we have to go back and
retrofit anything.

And I also want to tweak the characterization of that, below, because
I suspect this is unevenly understood, so far:

> 
> fn add(base: u64, off: i32) -> u64 {
>     base + off
> }
> 
> error[E0308]: mismatched types
>  --> add.rs:2:12
>   |
> 2 |     base + off
>   |            ^^^ expected `u64`, found `i32`
> 
> error[E0277]: cannot add `i32` to `u64`
>  --> add.rs:2:10
>   |
> 2 |     base + off
>   |          ^ no implementation for `u64 + i32`
>   |
>   = help: the trait `Add<i32>` is not implemented for `u64`
>   = help: the following other types implement trait `Add<Rhs>`:
>             <u64 as Add>
>             <u64 as Add<&u64>>
>             <&'a u64 as Add<u64>>
>             <&u64 as Add<&u64>>
> 
> so the Rust language people have clearly decided that this is too
> complicated for your average programmer to figure out, and you need
> explicit casts to make it work.


A couple of key points, though:

a) There are many other, better options than casts (Rust's "as"
keyword).

In fact, Rust doesn't actually require casts here, but it does require
something to explicitly declare the programmer's intentions.

b) Rust doesn't do this because programmers are too dumb to figure it
out. On the contrary, programmers are required to specify exactly what
they want, in the first place.

Some examples, using Matthew's example as a starting point:

// u64 add operations:
//   +                          - panics on overflow (debug), wraps (release)
//   wrapping_add(u64)          - always wraps
//   wrapping_add_signed(i64)   - always wraps, accepts signed offset
//   checked_add(u64)           - returns Option, None on overflow
//   checked_add_signed(i64)    - returns Option, None on overflow
//   saturating_add(u64)        - clamps to u64::MAX
//   saturating_add_signed(i64) - clamps to 0 or u64::MAX
//   overflowing_add(u64)       - returns (result, bool)
//   overflowing_add_signed(i64)- returns (result, bool)
//   strict_add(u64)            - always panics on overflow (even release)
//   unchecked_add(u64)         - UB on overflow (unsafe, for optimization)
//   carrying_add(u64, bool)    - multi-word arithmetic, returns (result, carry)

// 1. Wrapping: overflow/underflow wraps around (address arithmetic)
fn add_wrapping(base: u64, off: i32) -> u64 {
    base.wrapping_add_signed(i64::from(off))
}

// 2. Checked: returns None on overflow/underflow
fn add_checked(base: u64, off: i32) -> Option<u64> {
    base.checked_add_signed(i64::from(off))
}

// 3. Saturating: clamps to 0 or u64::MAX
fn add_saturating(base: u64, off: i32) -> u64 {
    base.saturating_add_signed(i64::from(off))
}

// 4. Overflowing: returns (result, did_overflow)
fn add_overflowing(base: u64, off: i32) -> (u64, bool) {
    base.overflowing_add_signed(i64::from(off))
}

fn main() {
    let base: u64 = 0x100;
    let off: i32 = -0x200;

    println!("base=0x{:x}, off={} (underflow case)", base, off);
    println!("wrapping:    0x{:x}", add_wrapping(base, off));
    println!("checked:     {:?}", add_checked(base, off));
    println!("saturating:  0x{:x}", add_saturating(base, off));
    println!("overflowing: {:?}", add_overflowing(base, off));
}

// Output:
base=0x100, off=-512 (underflow case)
wrapping:    0xffffffffffffff00
checked:     None
saturating:  0x0
overflowing: (18446744073709551360, true)


thanks,
-- 
John Hubbard