Re: [PATCH] rust/drm/gem: initialize callbacks with ..pin_init::zeroed()

[Klara Modin]

On 2026-09-08 18:05:54 +0000, sashiko-bot@xxxxxxxxxx wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Incomplete fix: missing `handle_free` field in conditionally compiled `shmem.rs`.
> --
> 
> commit b5b83bb373847c99ca6d286c268d2e0ffab299f0
> Author: Klara Modin <klarasmodin@xxxxxxxxx>
> 
> rust/drm/gem: initialize callbacks with ..pin_init::zeroed()
> 
> This commit updates the drm_gem_object_funcs struct initialization in the DRM
> GEM module to use pin_init::zeroed() instead of explicitly assigning None to
> unused callbacks. This fixes a build failure caused by a newly added callback
> field in the C structure.
> 
> Closes: https://lore.kernel.org/all/aaef18cd-ab55-4fb8-8563-ca3a5ea9cbc6@xxxxxxxxxxxxx
> 
> > diff --git a/rust/kernel/drm/gem/mod.rs b/rust/kernel/drm/gem/mod.rs
> > index e1ebad77ebe2a..c63b0fe5a15e1 100644
> > --- a/rust/kernel/drm/gem/mod.rs
> > +++ b/rust/kernel/drm/gem/mod.rs
> > @@ -266,18 +266,8 @@ impl<T: DriverObject, Ctx: DeviceContext> Object<T, Ctx> {
> >          free: Some(Self::free_callback),
> >          open: Some(open_callback::<T>),
> >          close: Some(close_callback::<T>),
> > -        print_info: None,
> > -        export: None,
> > -        pin: None,
> > -        unpin: None,
> > -        get_sg_table: None,
> > -        vmap: None,
> > -        vunmap: None,
> > -        mmap: None,
> > -        status: None,
> >          vm_ops: core::ptr::null_mut(),
> > -        evict: None,
> > -        rss: None,
> > +        ..pin_init::zeroed()
> >      };
> 
> [Severity: Medium]-
> Does this commit miss a similar update in rust/kernel/drm/gem/shmem.rs?
> 
> The VTABLE initialization in shmem.rs explicitly lists fields without
> using pin_init::zeroed(), similar to what was fixed here. When compiling
> with CONFIG_RUST_DRM_GEM_SHMEM_HELPER=y, won't this cause a missing
> field error for the newly added handle_free callback?

Sure, but it should probably be a different patch in that case. The
current patch fixes an issue to a currently existing build failure,
while the issue mentioned here has not manifested yet.

Regards,
Klara Modin

> 
> rust/kernel/drm/gem/shmem.rs:
>     const VTABLE: bindings::drm_gem_object_funcs = bindings::drm_gem_object_funcs {
>         free: Some(Self::free_callback),
>         open: Some(super::open_callback::<T>),
>         close: Some(super::close_callback::<T>),
>         print_info: Some(bindings::drm_gem_shmem_object_print_info),
>         export: None,
>         pin: Some(bindings::drm_gem_shmem_object_pin),
>         unpin: Some(bindings::drm_gem_shmem_object_unpin),
>         get_sg_table: Some(bindings::drm_gem_shmem_object_get_sg_table),
>         vmap: Some(bindings::drm_gem_shmem_object_vmap),
>         vunmap: Some(bindings::drm_gem_shmem_object_vunmap),
>         mmap: Some(bindings::drm_gem_shmem_object_mmap),
>         status: None,
>         rss: None,
>         #[allow(unused_unsafe, reason = "Safe since Rust 1.82.0")]
>         // SAFETY: drm_gem_shmem_vm_ops is a valid, static const on the C side.
>         vm_ops: unsafe { &raw const bindings::drm_gem_shmem_vm_ops },
>         evict: None,
>     };
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260908175427.47207-1-klarasmodin@xxxxxxxxx?part=1