Re: [PATCH v3 2/2] rust: uaccess: use NonEmpty in strcpy_into_buf()

[Gary Guo]

On Thu Oct 15, 2026 at 2:06 PM BST, Alexandre Courbot wrote:
> On Wed Oct 14, 2026 at 5:30 PM JST, Lorenzo Delgado wrote:
> <...>
>> diff --git a/rust/kernel/uaccess.rs b/rust/kernel/uaccess.rs
>> index 5f6c4d7a1a51..1cc5c7580d3a 100644
>> --- a/rust/kernel/uaccess.rs
>> +++ b/rust/kernel/uaccess.rs
>> @@ -11,6 +11,7 @@
>>      error::Result,
>>      ffi::{c_char, c_void},
>>      fs::file,
>> +    non_empty::NonEmpty,
>>      prelude::*,
>>      ptr::KnownSize,
>>      transmute::{AsBytes, FromBytes},
>> @@ -383,20 +384,16 @@ pub fn read_all<A: Allocator>(mut self, buf: &mut Vec<u8, A>, flags: Flags) -> R
>>      /// Read a NUL-terminated string from userspace and return it.
>>      ///
>>      /// The string is read into `buf` and a NUL-terminator is added if the end of `buf` is reached.
>> -    /// Since there must be space to add a NUL-terminator, the buffer must not be empty. The
>> +    /// Since there must be space to add a NUL-terminator, `buf` is a [`NonEmpty`] slice. The
>>      /// returned `&CStr` points into `buf`.
>>      ///
>>      /// Fails with [`EFAULT`] if the read happens on a bad address (some data may have been
>>      /// copied).
>>      #[doc(alias = "strncpy_from_user")]
>> -    pub fn strcpy_into_buf<'buf>(self, buf: &'buf mut [u8]) -> Result<&'buf CStr> {
>> -        if buf.is_empty() {
>> -            return Err(EINVAL);
>> -        }
>> -
>> +    pub fn strcpy_into_buf<'buf>(self, buf: &'buf mut NonEmpty<[u8]>) -> Result<&'buf CStr> {
>
> I understand this was done per the v1 feedback, but won't it make it
> more tedious for users to call this method? (hard to tell as there are
> no users at the moment :))
>
> We could still benefit from `NonEmpty` if we replace the `buf.is_empty`
> by an attempt to build it and return `EINVAL` if that fails (what v1 did
> basically) and calling `last_mut` on it to remove the
> `unwrap_unchecked`.
>
> Of course if callers are expected to already work with a `NonEmpty` then
> that's fine, but otherwise my concern is that every one of them would
> have to manually build one to perform a check that this method can
> easily do.

I think it might also be reasonable to invoke errorenous behaviour here, by do a
`WARN` and just return c""?

Best,
Gary