All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jayant Shekhar" <jayant.shekhar@oss.qualcomm.com>
Cc: virtualization@lists.linux.dev, dri-devel@lists.freedesktop.org,
	devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org,
	media-ci@linuxtv.org, "Michael S. Tsirkin" <mst@redhat.com>,
	"Eugenio Perez" <eperezma@redhat.com>
Subject: Re: [PATCH v2 13/23] drm/msm/dcp: Route HFI display events
Date: Mon, 26 Oct 2026 12:08:52 +0000	[thread overview]
Message-ID: <sashiko-outbox-185169@kernel.org> (raw)
In-Reply-To: <20261026-jshekhar-dcp-hlos-v2-13-7cf014efdee1@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] drm/msm/dcp: unsynchronized frame done state in dcp_crtc_hfi_frame_done_cb()
- [Medium] drm/msm/dcp: missing payload validation in dcp_hfi_dispatch_frame_done()
--

commit 7606ba3e12102c6ab2bc26f57c18f121dc3e91f7
Author: Jayant Shekhar <jayant.shekhar@oss.qualcomm.com>

drm/msm/dcp: Route HFI display events

This commit routes asynchronous HFI VSYNC and frame-scan completion display
events from DCP firmware to the corresponding DRM CRTC callbacks, and adds a
NULL check for dma_dev in dcp_hfi_init().

> diff --git a/drivers/gpu/drm/msm/dcp/dcp_hfi_core.c b/drivers/gpu/drm/msm/dcp/dcp_hfi_core.c
> index 774a5afac0f0a..e54ccfafdae0f 100644
> --- a/drivers/gpu/drm/msm/dcp/dcp_hfi_core.c
> +++ b/drivers/gpu/drm/msm/dcp/dcp_hfi_core.c
> @@ -19,6 +19,7 @@
>  #include "dcp_hfi.h"
>  #include "dcp_hfi_priv.h"
>  #include "dcp_drv.h"
> +#include "dcp_crtc.h"
>  #include "hfi/hfi_packet.h"
>  #include "hfi/hfi_packer.h"
>  #include "hfi/hfi_unpacker.h"
> @@ -260,18 +261,35 @@ static void dcp_hfi_store_caps_payload(struct dcp_hfi *hfi,
>  	dev_dbg(hfi->dev, "%s: stored %u bytes\n", name, n);
>  }
>  
> +static void dcp_hfi_dispatch_frame_done(struct dcp_hfi *hfi,
> +					const struct hfi_packet_info *pkt_info)
> +{
> +	const struct hfi_display_frame_event_data *frame = NULL;
> +	u32 sequence_id = 0;
> +
> +	if (pkt_info->payload_ptr &&
> +	    pkt_info->payload_size >= sizeof(*frame)) {
> +		frame = pkt_info->payload_ptr;
> +		sequence_id = frame->bufferflip_index;
> +	}
> +	dcp_crtc_hfi_frame_done_cb(hfi->drv, pkt_info->id & 0xFFFF,
> +				   sequence_id);
> +}

[Severity: Medium]
Should dcp_hfi_dispatch_frame_done() drop the packet and return early when
pkt_info->payload_ptr is NULL or pkt_info->payload_size is smaller than
sizeof(*frame)?

As written, a truncated or empty HFI_COMMAND_DISPLAY_EVENT_FRAME_SCAN_COMPLETE
packet falls through and invokes dcp_crtc_hfi_frame_done_cb() with a
fabricated sequence_id of 0:

drivers/gpu/drm/msm/dcp/dcp_crtc.c:dcp_crtc_hfi_frame_done_cb() {
	...
	if (crtc) {
		struct dcp_crtc *dcp_crtc = to_dcp_crtc(crtc);

		/* A single pending commit makes equality valid across sequence wrap. */
		if (sequence_id != dcp_crtc->pending_seq_id) {
			drm_warn(crtc->dev,
				 "CRTC%u: ignoring stale FRAME_SCAN_COMPLETE seq=%u expected=%u\n",
				 dcp_crtc->display_id, sequence_id,
				 dcp_crtc->pending_seq_id);
			return;
		}
		dcp_crtc_frame_done_callback(crtc);
	}
	...
}

If dcp_crtc->pending_seq_id happens to be 0 (such as before the first commit
sequence is latched or when the 32-bit commit_seq_id counter wraps around to
0), this will falsely match pending_seq_id and prematurely complete the frame.
When pending_seq_id is non-zero, it logs an unratelimited warning for a bogus
sequence 0 event.

> +
>  /* Route asynchronous events and capability packets before flag handling. */
>  static bool dcp_hfi_dispatch_event(struct dcp_hfi *hfi,
>  				   const struct hfi_packet_info *pkt_info)
>  {
>  	switch (pkt_info->cmd) {
>  	case HFI_COMMAND_DISPLAY_EVENT_VSYNC:
> +		dcp_crtc_hfi_vblank_cb(hfi->drv, pkt_info->id & 0xFFFF);
>  		return true;
>  
>  	case HFI_COMMAND_DISPLAY_EVENT_FRAME_SCAN_START:
>  		return true;
>  
>  	case HFI_COMMAND_DISPLAY_EVENT_FRAME_SCAN_COMPLETE:
> +		dcp_hfi_dispatch_frame_done(hfi, pkt_info);
>  		return true;

[Severity: High]
With HFI_COMMAND_DISPLAY_EVENT_FRAME_SCAN_COMPLETE now routed from the
asynchronous VirtIO response callback (dcp_hfi_resp_callback() ->
dcp_hfi_dispatch_event() -> dcp_hfi_dispatch_frame_done()) into
dcp_crtc_hfi_frame_done_cb(), can concurrent access to dcp_crtc->pending_seq_id
and dcp_crtc->pending_kickoff_cnt race with the commit path?

In drivers/gpu/drm/msm/dcp/dcp_crtc.c, dcp_crtc_commit_kickoff() updates
pending_kickoff_cnt and pending_seq_id without lock synchronization against
dcp_crtc_hfi_frame_done_cb():

	if (atomic_cmpxchg(&dcp_crtc->pending_kickoff_cnt, 0, 1)) {
		drm_err(crtc->dev,
			"CRTC%u: frame completion already pending\n",
			dcp_crtc->display_id);
		cstate->hfi_error = -EBUSY;
		return;
	}
	dcp_crtc->pending_seq_id = dcp_crtc->commit_seq_id;

	ret = dcp_hfi_display_commit(dcp_kms->hfi, session_id);
	if (ret) {
		drm_err(crtc->dev,
			"HFI commit failed for CRTC%u (session=%u): %d\n",
			dcp_crtc->display_id, session_id, ret);
		atomic_dec(&dcp_crtc->pending_kickoff_cnt);
		wake_up(&dcp_crtc->frame_done_wq);
	}

This appears to allow several races when asynchronous frame-done events arrive:

1. pending_kickoff_cnt is set to 1 before dcp_crtc->pending_seq_id is updated
to dcp_crtc->commit_seq_id. If a FRAME_SCAN_COMPLETE event carrying the
previous sequence ID arrives in that window (for example after a prior commit
timeout in dcp_crtc_wait_for_commit_done() reset pending_kickoff_cnt to 0 while
leaving pending_seq_id at the old value, or from periodic scanout),
dcp_crtc_hfi_frame_done_cb() sees sequence_id == dcp_crtc->pending_seq_id and
calls dcp_crtc_frame_done_callback(), decrementing pending_kickoff_cnt back to
0 before dcp_hfi_display_commit() even runs.

2. If dcp_crtc_frame_done_callback() decrements pending_kickoff_cnt from 1 to
0 (either via the window above or because firmware sent FRAME_SCAN_COMPLETE
while dcp_hfi_display_commit() timed out waiting for the command response) and
dcp_hfi_display_commit() returns an error, the error path unconditionally runs
atomic_dec(&dcp_crtc->pending_kickoff_cnt), underflowing pending_kickoff_cnt to
-1. Because dcp_crtc_frame_done_callback() uses
atomic_add_unless(&dcp_crtc->pending_kickoff_cnt, -1, 0), subsequent frame-done
events will decrement it further (-2, -3, ...) and cause future commits to
stall until DCP_FRAME_DONE_TIMEOUT_MS expires.

3. In dcp_crtc_atomic_flush(), ++dcp_crtc->commit_seq_id is sent to firmware
via dcp_hfi_crtc_set_scan_sequence_id() and autorefresh is enabled via
dcp_hfi_crtc_set_autorefresh() before dcp_crtc_commit_kickoff() sets
pending_seq_id and pending_kickoff_cnt. If firmware emits a FRAME_SCAN_COMPLETE
event for the new sequence ID before dcp_crtc_commit_kickoff() updates
pending_seq_id, dcp_crtc_hfi_frame_done_cb() will drop it as a stale sequence
mismatch.

Should pending_seq_id and pending_kickoff_cnt updates and checks be
synchronized under a spinlock across the flush, kickoff, and HFI callback
paths?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261026-jshekhar-dcp-hlos-v2-0-7cf014efdee1@oss.qualcomm.com?part=13

  reply	other threads:[~2026-10-26 12:08 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-26  6:21 [PATCH v2 00/23] drm/msm/dcp: Add Qualcomm DCP display support Jayant Shekhar
2026-10-26  6:21 ` [PATCH v2 01/23] dt-bindings: display: msm: Add Qualcomm DCP Jayant Shekhar
2026-10-26  9:38   ` sashiko-bot
2026-10-26  9:57   ` Dmitry Baryshkov
2026-10-26 19:44   ` Rob Herring (Arm)
2026-10-27  8:36   ` Krzysztof Kozlowski
2026-10-26  6:21 ` [PATCH v2 02/23] drm/msm/dcp: Add HFI packet helpers Jayant Shekhar
2026-10-26  9:48   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 03/23] drm/msm/dcp: Add HFI device definitions Jayant Shekhar
2026-10-26  9:50   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 04/23] drm/msm/dcp: Add HFI display definitions Jayant Shekhar
2026-10-26  9:52   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 05/23] drm/msm/dcp: Add HFI panel definitions Jayant Shekhar
2026-10-26  9:54   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 06/23] drm/msm/dcp: Add HFI VirtIO transport Jayant Shekhar
2026-10-26 10:07   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 07/23] drm/msm/dcp: Handle asynchronous HFI responses Jayant Shekhar
2026-10-26 10:22   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 08/23] drm/msm/dcp: Add IPCC power notifications Jayant Shekhar
2026-10-26 10:36   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 09/23] drm/msm/dcp: Add generic HFI display commands Jayant Shekhar
2026-10-26 10:52   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 10/23] drm/msm/dcp: Add HFI DSI and panel commands Jayant Shekhar
2026-10-26 11:13   ` sashiko-bot
2026-10-27 11:06   ` Dmitry Baryshkov
2026-10-26  6:21 ` [PATCH v2 11/23] drm/msm/dcp: Add DCP CRTCs and shared plane state Jayant Shekhar
2026-10-26 10:49   ` Dmitry Baryshkov
2026-10-26 11:33   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 12/23] drm/msm/dcp: Add DCP planes Jayant Shekhar
2026-10-26 11:57   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 13/23] drm/msm/dcp: Route HFI display events Jayant Shekhar
2026-10-26 12:08   ` sashiko-bot [this message]
2026-10-26  6:21 ` [PATCH v2 14/23] drm/msm/dcp: Add DCP encoder Jayant Shekhar
2026-10-26 12:11   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 15/23] drm/msm/dcp: Add DCP DSI host and panel support Jayant Shekhar
2026-10-26 11:08   ` Dmitry Baryshkov
2026-10-26 12:37   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 16/23] drm/msm/dcp: Integrate the DSI bridge with KMS Jayant Shekhar
2026-10-26 13:03   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 17/23] drm/msm/dcp: Register DCP display pipeline Jayant Shekhar
2026-10-26 13:24   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 18/23] virtio: Add Qualcomm Platform Services Firmware Interface ID Jayant Shekhar
2026-10-26  9:59   ` Dmitry Baryshkov
2026-10-26 10:27   ` Michael S. Tsirkin
2026-10-26 13:48   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 19/23] drm/msm/dcp: Add Qualcomm VirtIO transport wrapper Jayant Shekhar
2026-10-26 10:07   ` Dmitry Baryshkov
2026-10-26 14:05   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 20/23] drm/msm/dcp: Add DCP VirtIO driver Jayant Shekhar
2026-10-26 10:15   ` Dmitry Baryshkov
2026-10-26 14:31   ` sashiko-bot
2026-10-26  6:21 ` [PATCH v2 21/23] drm/msm: Support KMS backends without a display IRQ Jayant Shekhar
2026-10-26 14:40   ` sashiko-bot
2026-10-27 11:37   ` Dmitry Baryshkov
2026-10-26  6:21 ` [PATCH v2 22/23] drm/msm: Register the DCP backend Jayant Shekhar
2026-10-26 14:58   ` sashiko-bot
2026-10-27 11:38   ` Dmitry Baryshkov
2026-10-26  6:21 ` [PATCH v2 23/23] arm64: dts: qcom: hawi: Add DCP support Jayant Shekhar
2026-10-26 15:10   ` sashiko-bot
2026-10-27 11:44   ` Dmitry Baryshkov
2026-10-27 11:58 ` [PATCH v2 00/23] drm/msm/dcp: Add Qualcomm DCP display support Dmitry Baryshkov

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-185169@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eperezma@redhat.com \
    --cc=jayant.shekhar@oss.qualcomm.com \
    --cc=media-ci@linuxtv.org \
    --cc=mst@redhat.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=virtualization@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.