All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ze Huang" <ze.huang@oss.qualcomm.com>
Cc: Frank.Li@kernel.org, imx@lists.linux.dev,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 6/9] drm/gm12u320: replace struct drm_simple_display_pipe with regular atomic helpers
Date: Sat, 04 Jul 2026 18:45:38 +0000	[thread overview]
Message-ID: <20260704184538.E20261F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260705-drm-simple-kms-removal-v1-6-b4e1ca053623@oss.qualcomm.com>

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

New issues:
- [High] Race condition and potential NULL pointer dereference due to direct access to `plane->state` and missing visibility checks in atomic callbacks.

Pre-existing issues:
- [High] Sleeping in atomic context within CRTC and plane atomic callbacks.
--

commit a10b3d5781e3b7143f432c86643ef47e8ddc3a9a
Author: Ze Huang <ze.huang@oss.qualcomm.com>

drm/gm12u320: replace struct drm_simple_display_pipe with regular atomic helpers

Convert gm12u320 to direct primary plane, CRTC and encoder setup.
Keep shadow-plane helper state, framebuffer access helpers and
no-scaling plane-state check from simple-KMS path.

> diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c
> index 4ad074337af07..b476793d0401e 100644
> --- a/drivers/gpu/drm/tiny/gm12u320.c
> +++ b/drivers/gpu/drm/tiny/gm12u320.c

[ ... ]

> +static void gm12u320_crtc_helper_atomic_enable(struct drm_crtc *crtc,
> +					       struct drm_atomic_commit *commit)
>  {
>  	struct drm_rect rect = { 0, 0, GM12U320_USER_WIDTH, GM12U320_HEIGHT };
> -	struct gm12u320_device *gm12u320 = to_gm12u320(pipe->crtc.dev);
> +	struct gm12u320_device *gm12u320 = to_gm12u320(crtc->dev);
> +	struct drm_plane_state *plane_state = crtc->primary->state;

[Severity: High]
Will this cause a NULL pointer dereference if a subsequent commit disables
the plane?

Because non-blocking commits execute asynchronously, crtc->primary->state
reflects the state of the most recently queued commit, rather than the
commit currently executing. If a fast subsequent commit disables the plane,
plane_state->fb could be NULL.

Should this use drm_atomic_get_new_plane_state(commit, crtc->primary) to
get the state tied to this specific commit?

>  	struct drm_shadow_plane_state *shadow_plane_state = to_drm_shadow_plane_state(plane_state);
>  
>  	gm12u320->fb_update.draw_status_timeout = FIRST_FRAME_TIMEOUT;
>  	gm12u320_fb_mark_dirty(plane_state->fb, &shadow_plane_state->data[0], &rect);
>  }
>  
> -static void gm12u320_pipe_disable(struct drm_simple_display_pipe *pipe)
> +static void gm12u320_crtc_helper_atomic_disable(struct drm_crtc *crtc,
> +						struct drm_atomic_commit *commit)
>  {
> -	struct gm12u320_device *gm12u320 = to_gm12u320(pipe->crtc.dev);
> +	struct gm12u320_device *gm12u320 = to_gm12u320(crtc->dev);
>  
>  	gm12u320_stop_fb_update(gm12u320);

[Severity: High]
This isn't a bug introduced by this patch, but does gm12u320_stop_fb_update()
sleep in atomic context?

gm12u320_stop_fb_update() calls cancel_delayed_work_sync() and mutex_lock().
Since CRTC atomic disable callbacks can run in atomic context during
non-blocking commits, sleeping here is forbidden and could cause kernel
warnings or deadlocks.

>  }
>  
> -static void gm12u320_pipe_update(struct drm_simple_display_pipe *pipe,
> -				 struct drm_plane_state *old_state)
> +static void gm12u320_plane_helper_atomic_update(struct drm_plane *plane,
> +						struct drm_atomic_commit *commit)
>  {
> -	struct drm_plane_state *state = pipe->plane.state;
> +	struct drm_plane_state *old_state = drm_atomic_get_old_plane_state(commit, plane);
> +	struct drm_plane_state *state = plane->state;

[Severity: High]
Could accessing plane->state directly here lead to a crash?

Similar to the CRTC enable function, reading plane->state directly instead of
using drm_atomic_get_new_plane_state(commit, plane) accesses the future
state.

If a subsequent commit disables the plane, state->fb will be NULL. In this
scenario, drm_atomic_helper_damage_merged() returns true for plane
disablements, leading to gm12u320_fb_mark_dirty() being called with a NULL
fb, which will oops when trying to dereference fb->dev.

This wasn't possible before because the drm_simple_kms_helper explicitly
checked if (!plane->state->visible) before calling the update hook, but
that protection is dropped in this conversion.

> +	struct drm_shadow_plane_state *shadow_plane_state = to_drm_shadow_plane_state(state);
>  	struct drm_rect rect;
>  
> -	if (drm_atomic_helper_damage_merged(old_state, state, &rect))
> +	if (drm_atomic_helper_damage_merged(old_state, state, &rect))
>  		gm12u320_fb_mark_dirty(state->fb, &shadow_plane_state->data[0], &rect);

[Severity: High]
This is a pre-existing issue, but does gm12u320_fb_mark_dirty() sleep in
atomic context?

It calls mutex_lock(&gm12u320->fb_update.lock), which is unsafe to call
from a plane update callback during non-blocking commits, as these run
in atomic context.

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260705-drm-simple-kms-removal-v1-0-b4e1ca053623@oss.qualcomm.com?part=6

  reply	other threads:[~2026-07-04 18:45 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-04 18:31 [PATCH 0/9] drm: replace simple display pipe users with atomic helpers Ze Huang
2026-07-04 18:31 ` [PATCH 1/9] drm/arcpgu: replace struct drm_simple_display_pipe with regular " Ze Huang
2026-07-04 18:43   ` sashiko-bot
2026-07-06  7:43     ` Thomas Zimmermann
2026-07-06  8:01   ` Thomas Zimmermann
2026-07-06 13:26     ` Ze Huang
2026-07-04 18:31 ` [PATCH 2/9] drm/aspeed: " Ze Huang
2026-07-04 18:52   ` sashiko-bot
2026-07-06  8:31   ` Thomas Zimmermann
2026-07-06 13:32     ` Ze Huang
2026-07-04 18:31 ` [PATCH 3/9] drm/imx: " Ze Huang
2026-07-04 18:46   ` sashiko-bot
2026-07-08 13:02     ` Ze Huang
2026-07-08 12:44   ` Thomas Zimmermann
2026-07-08 13:07     ` Ze Huang
2026-07-04 18:31 ` [PATCH 4/9] drm/mcde: " Ze Huang
2026-07-04 18:44   ` sashiko-bot
2026-07-08 14:44     ` Ze Huang
2026-07-08 13:02   ` Thomas Zimmermann
2026-07-08 14:04     ` Ze Huang
2026-07-04 18:31 ` [PATCH 5/9] drm/pl111: " Ze Huang
2026-07-04 18:45   ` sashiko-bot
2026-07-08 13:03   ` Thomas Zimmermann
2026-07-08 14:46     ` Ze Huang
2026-07-04 18:31 ` [PATCH 6/9] drm/gm12u320: " Ze Huang
2026-07-04 18:45   ` sashiko-bot [this message]
2026-07-10  9:20     ` Thomas Zimmermann
2026-07-10  9:26       ` Thomas Zimmermann
2026-07-10  9:09   ` Thomas Zimmermann
2026-07-10  9:21     ` Thomas Zimmermann
2026-07-04 18:31 ` [PATCH 7/9] drm/repaper: " Ze Huang
2026-07-04 18:31 ` [PATCH 8/9] drm/tve200: " Ze Huang
2026-07-04 18:46   ` sashiko-bot
2026-07-08 15:17     ` Ze Huang
2026-07-04 18:31 ` [PATCH 9/9] drm/xen: " Ze Huang
2026-07-04 18:53   ` sashiko-bot
2026-07-08 15:29     ` Ze Huang
2026-07-06  7:27 ` [PATCH 0/9] drm: replace simple display pipe users with " Thomas Zimmermann
2026-07-06  8:22   ` Ze Huang
2026-07-08 12:42     ` Thomas Zimmermann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260704184538.E20261F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=imx@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=ze.huang@oss.qualcomm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.