Re: [PATCH v5 2/8] rust: firmware: add request_into_buf()

On Sat Jul 11, 2026 at 8:04 AM JST, Timur Tabi wrote:
<snip>
> @@ -120,6 +121,50 @@ fn drop(&mut self) {
>      }
>  }
> =20
> +/// Load firmware directly into the caller-provided `buf`.
> +///
> +/// On success the firmware image has been copied into `buf`; the caller=
 accesses the data
> +/// through `buf` itself.
> +///
> +/// This is intentionally a stand-alone function rather than a `Firmware=
` constructor. For
> +/// the `into_buf` path, the firmware data lives in the caller's `buf`, =
not in a
> +/// kernel-owned buffer, so returning a `Firmware` would expose `Firmwar=
e::data()` as a
> +/// second handle aliasing `buf` (and `release_firmware()` does not free=
 `buf` anyway).
> +pub fn request_into_buf(name: &CStr, dev: &Device, buf: &mut [u8]) -> Re=
sult {
> +    // `as_mut_ptr()` on an empty slice returns a non-NULL pointer to
> +    // memory which the loader does not own. Passing that pointer with `=
size =3D=3D 0`
> +    // makes the loader believe that it is buffer it allocated itself, s=
o when
> +    // `release_firmware()` is called, it will vfree the pointer and tri=
gger a
> +    // bug. Reject empty slices to avoid this situation.
> +    if buf.is_empty() {
> +        return Err(EINVAL);
> +    }
> +
> +    let mut fw: *mut bindings::firmware =3D core::ptr::null_mut();
> +    let pfw: *mut *mut bindings::firmware =3D &mut fw;
> +    let pfw: *mut *const bindings::firmware =3D pfw.cast();
> +
> +    // SAFETY: `pfw` is a valid pointer to a NULL initialized `bindings:=
:firmware` pointer.
> +    // `name` and `dev` are valid as by their type invariants. `buf` is =
a valid writable
> +    // buffer of `buf.len()` bytes.\

Stray `\` here on the last line.