From: sashiko-bot@kernel.org
To: "Michael Burch" <me@michaelburch.net>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/msm/dpu: count the pending frame before kicking it off
Date: Tue, 13 Oct 2026 15:04:13 +0000 [thread overview]
Message-ID: <sashiko-outbox-169964@kernel.org> (raw)
In-Reply-To: <20261013145007.13111-1-me@michaelburch.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/msm/dpu: bandwidth leak due to missed frame_pending 0-transition in error path
--
commit 09d9db34ac4a7e898d02571dc93cd542a14a8979
Author: Michael Burch <me@michaelburch.net>
drm/msm/dpu: count the pending frame before kicking it off
This commit moves the increment of frame_pending in dpu_crtc_commit_kickoff()
to occur before kickoff to prevent event worker races. It also adds a rollback
decrement in the clone mode error path.
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 42d0a529b4d51..c8bd9c305a59a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
[ ... ]
> @@ -1105,9 +1105,19 @@ void dpu_crtc_commit_kickoff(struct drm_crtc *crtc)
> }
> }
>
> + /* The frame-done event may be handled before the kickoff below returns. */
> + if (atomic_inc_return(&dpu_crtc->frame_pending) == 1) {
> + /* acquire bandwidth and other resources */
> + DRM_DEBUG_ATOMIC("crtc%d first commit\n", crtc->base.id);
> + } else {
> + DRM_DEBUG_ATOMIC("crtc%d commit\n", crtc->base.id);
> + }
> +
> if (drm_crtc_in_clone_mode(crtc->state)) {
> - if (dpu_crtc_kickoff_clone_mode(crtc))
> + if (dpu_crtc_kickoff_clone_mode(crtc)) {
> + atomic_dec(&dpu_crtc->frame_pending);
[Severity: Medium]
Does this unconditional atomic_dec() bypass the 0-transition check required to
release CRTC bandwidth, causing a bandwidth leak?
If Frame N-1 is executing and Frame N is committed, dpu_crtc_commit_kickoff()
bumps frame_pending to 2. If dpu_crtc_kickoff_clone_mode() fails, it
decrements the count back.
If the hardware interrupt for Frame N-1 fires concurrently and its event worker
runs, it will decrement the count to 1, skipping the
dpu_core_perf_crtc_release_bw() call that requires a 1-to-0 transition.
The error path then blindly decrements the count to 0 with atomic_dec() and
also skips the dpu_core_perf_crtc_release_bw() call, permanently leaking the
allocated bandwidth until the CRTC is fully disabled.
> goto end;
> + }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261013145007.13111-1-me@michaelburch.net?part=1
parent reply other threads:[~2026-10-13 15:04 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20261013145007.13111-1-me@michaelburch.net>]
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=sashiko-outbox-169964@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=me@michaelburch.net \
--cc=sashiko-reviews@lists.linux.dev \
/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.