Re: [PATCH v5 5/5] gpu: nova-core: add ChannelIdPool

On Tue Aug 18, 2026 at 12:40 AM CEST, Yury Norov wrote:
> Again, any kernel API trusts it's caller. It holds for assembler,
> for C, and I don't see any reason why it shouldn't hold for Rust.

This argument is misleading in this context, because it is conflating "trusting
the caller" with "trusting the value".

The kernel's APIs generally do trust the caller (and even that does not always
hold), but they do not necessarily trust the arguments passed by a caller; this
entirely depends on the API contract.

And this makes a lot of sense; sometimes values originate from untrusted
sources, such as userspace.

But even if there is a clearly expressed API contract for the bounds of a value,
kernel APIs regularly do still check their validity.

For instance, do_mmap() does return -EINVAL if !len, despite the documentation
(*1) even saying:

	@len: The length of the mapping. Will be page-aligned and must be at
	      least 1 page in size.

In this case one reason is layering, the len argument *may* originate from
userspace, but it does not always originate from userspace (i.e. an untrusted
source).

So, if we'd write do_mmap() in Rust, it would be a perfect candidate for len
being NonZero.

This way there's only a single do_mmap() function, that doesn't need to bother
with a runtime check for len, because the argument already holds that invariant.

The way the invariant is obtained depends on the call site. If the value comes
from userspace, you do a fallible check

	let len = NonZero::new(len).ok_or(EINVAL)?;

If the value is known at compile time you can instead call

	let len = nz!(PAGE_SIZE);

which is checked at compile time.

Maybe you also already got a NonZero value from a different API that already
obtained the non-zero invariant that you just pass through.

It nicely separates the code that validates the value from the user of the
value, where the user of the value is only interested in the required invariant,
but not how the invariant is obtained.

IOW, do_mmap() does not care (and should not care) how the caller ensures that
len != 0.

> And undef isn't the case for alloc(0) - instead of making non-zero 'size' a
> part of API contract, we must make the function behavior well defined for this
> case.

We should only do this if the return value does not depend on an argument's
invariant, in which case no invariant is needed in the first place.

> kmalloc(0), for example, returns ZERO_SIZE_PTR. The pool.alloc_area(0) may
> return None, and probably trigger some warning.

That's because ZERO_SIZE_PTR *is* a useful return value that adds real value
(even more useful in Rust with ZST). It does for instance allow you to write:

	items = kmalloc_array(n, sizeof(*items), GFP_KERNEL);
	if (!items)
	    return -ENOMEM;

	for (i = 0; i < n; i++)
	    process(items[i]);

	kfree(items);

However, reserve_ids() is not like kmalloc(), a ChannelIdArea with a zero range
isn't useful at all.

And returning Result<Option<ChannelIdArea>> is not useful either, as it would
move the validation through NonZero (which you want to avoid) back to the user
now having to validate the Option instead, which, for obvious reasons, is worse
given that it is actually an error condition: there's nothing optional here,
it's just that the input argument was wrong, so Ok(None) is even misleading.

(*1) do_mmap()

I think the documentation is slighly misleading, since it says "must be at least
1 page in size", but the actual requirement is non-zero. It's just that anything
that is not page aligned is rounded up, so any 0 < len < PAGE_SIZE ends up at
PAGE_SIZE too.