Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:

Pre-existing issues:
- [High] Unchecked return value of drm_atomic_private_obj_init() causes NULL 
pointer dereference in debugfs state dump.
--

commit 04438d5e8a74302c0e7fbf067a17289c1680b606
Author: Maxime Ripard <[email protected]>

drm/bridge: samsung-dsim: Switch to atomic_create_state

This commit replaces the deprecated atomic_reset callback with
atomic_create_state and its corresponding helper.

> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 9ee0515074c78..5788066d479e6 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1835,7 +1835,7 @@ static int samsung_dsim_attach(struct drm_bridge 
> *bridge,
>  static const struct drm_bridge_funcs samsung_dsim_bridge_funcs = {
>       .atomic_duplicate_state         = 
> drm_atomic_helper_bridge_duplicate_state,
>       .atomic_destroy_state           = 
> drm_atomic_helper_bridge_destroy_state,
> -     .atomic_reset                   = drm_atomic_helper_bridge_reset,
> +     .atomic_create_state                    = 
> drm_atomic_helper_bridge_create_state,
[Severity: High]
This is a pre-existing issue, but does switching to atomic_create_state expose
a bug with unchecked return values in drm_bridge_attach()?

In drivers/gpu/drm/drm_bridge.c:drm_bridge_attach(), the return value of
drm_atomic_private_obj_init() is ignored:

        if (drm_bridge_is_atomic(bridge))
                drm_atomic_private_obj_init(bridge->dev, &bridge->base,
                                            &drm_bridge_priv_state_funcs);

        return 0;

If memory allocation for the bridge's initial state fails (for instance, in
the newly assigned atomic_create_state callback), drm_bridge_attach()
still returns 0. The bridge probe falsely succeeds but bridge->base.state
remains NULL.

Because drm_atomic_private_obj_init() links the object into
dev->mode_config.privobj_list before attempting the state allocation,
the device's list is left containing a poisoned object with a NULL state.

Any subsequent trigger of the DRM state dump (e.g., via reading
/sys/kernel/debug/dri/*/state or SysRq-d) iterates over privobj_list and
unconditionally calls drm_atomic_private_obj_print_state():

drivers/gpu/drm/drm_atomic.c:drm_atomic_private_obj_print_state()
{
        struct drm_private_obj *obj = state->obj;
    ...
}

Since state is NULL, dereferencing state->obj triggers a kernel oops. Is this
something that should be addressed in the DRM bridge core?

>       .atomic_get_input_bus_fmts      = 
> samsung_dsim_atomic_get_input_bus_fmts,
>       .atomic_check                   = samsung_dsim_atomic_check,
>       .atomic_pre_enable              = samsung_dsim_atomic_pre_enable,

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/[email protected]?part=30

Reply via email to