From: sashiko-bot@kernel.org
To: "Adrián Larumbe" <adrian.larumbe@collabora.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v8 10/16] drm/panfrost: Add debugfs knob for manually triggering a GPU reset
Date: Mon, 07 Sep 2026 20:28:17 +0000 [thread overview]
Message-ID: <20260907202818.3B9DF1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260907-claude-fixes-v8-10-c2bcb5e82184@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incorrect error handling of pm_runtime_get_if_active() leads to unsafe hardware access when runtime PM is disabled.
--
commit 8d990169095e4c032a10ab3f7f2aa29eb0345717
Author: Adrián Larumbe <adrian.larumbe@collabora.com>
drm/panfrost: Add debugfs knob for manually triggering a GPU reset
This commit introduces a new debugfs file to manually schedule a GPU reset.
It is intended to help test potential race conditions between the reset
sequence and other hardware register accesses.
> diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c b/drivers/gpu/drm/panfrost/panfrost_device.c
> index f0fae6fa1e248..f171abe26f80d 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_device.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_device.c
[ ... ]
> +static int reset_set(void *data, u64 val)
> +{
> + struct panfrost_device *pfdev =
> + container_of(data, struct panfrost_device, base);
> + int ret = pm_runtime_get_if_active(pfdev->base.dev);
> +
> + if (ret) {
[Severity: High]
Can this cause a kernel panic if runtime PM is disabled?
pm_runtime_get_if_active() returns a negative error code (like -EINVAL)
when runtime PM is disabled, such as during system suspend. Because this
condition checks if (ret) instead of if (ret > 0), a negative error return
evaluates to true.
This would cause panfrost_device_schedule_reset() to execute and flush the
work queue while the device is potentially powered down, which may lead to
unclocked register accesses and a synchronous external abort (bus fault).
Should this condition be if (ret > 0) to ensure the device is genuinely
active before proceeding with the hardware reset?
> + panfrost_device_schedule_reset(pfdev);
> + flush_work(&pfdev->reset.work);
> + if (ret > 0)
> + pm_runtime_put(pfdev->base.dev);
> + }
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260907-claude-fixes-v8-0-c2bcb5e82184@collabora.com?part=10
next prev parent reply other threads:[~2026-09-07 20:28 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 20:16 [PATCH v8 00/16] Collection of fixes for Panfrost: Perfcnt, RPM, refactorings Adrián Larumbe
2026-09-07 20:16 ` [PATCH v8 01/16] drm/panfrost: Move shrinker initialization and unplug one level down Adrián Larumbe
2026-09-07 20:16 ` [PATCH v8 02/16] drm/panfrost: Move lock and modparam initialisations into their subsystems Adrián Larumbe
2026-09-07 20:16 ` [PATCH v8 03/16] drm/panfrost: Move debugfs initialisation to relevant subsystems Adrián Larumbe
2026-09-07 20:28 ` sashiko-bot
2026-09-07 20:16 ` [PATCH v8 04/16] drm/panfrost: Skip NULL checks for clock enable/disabling Adrián Larumbe
2026-09-07 20:16 ` [PATCH v8 05/16] drm/panfrost: Consolidate device clock management and reset Adrián Larumbe
2026-09-07 20:31 ` sashiko-bot
2026-09-07 20:16 ` [PATCH v8 06/16] drm/panfrost: Fix PM refcnt and autosuspend issues at device probe/remove Adrián Larumbe
2026-09-07 20:29 ` sashiko-bot
2026-09-07 20:16 ` [PATCH v8 07/16] drm/panfrost: Explicitly enable MMU interrupts at device init Adrián Larumbe
2026-09-07 20:31 ` sashiko-bot
2026-09-07 20:16 ` [PATCH v8 08/16] drm/panfrost: Move all DRM device initialisation into device_init() Adrián Larumbe
2026-09-07 20:16 ` [PATCH v8 09/16] drm/panfrost: Add warning messages to fatal error conditions Adrián Larumbe
2026-09-07 20:16 ` [PATCH v8 10/16] drm/panfrost: Add debugfs knob for manually triggering a GPU reset Adrián Larumbe
2026-09-07 20:28 ` sashiko-bot [this message]
2026-09-07 20:16 ` [PATCH v8 11/16] drm/panfrost: Move perfcnt GPU disable sequence into a helper Adrián Larumbe
2026-09-07 20:16 ` [PATCH v8 12/16] drm/panfrost: Skip cache flush/invalidate when enabling perfcnt Adrián Larumbe
2026-09-07 20:16 ` [PATCH v8 13/16] drm/panfrost: Avoid cache flush after perfcnt sample in fully coherent systems Adrián Larumbe
2026-09-07 20:35 ` sashiko-bot
2026-09-07 20:16 ` [PATCH v8 14/16] drm/panfrost: Introduce a reset lock Adrián Larumbe
2026-09-07 20:38 ` sashiko-bot
2026-09-07 20:16 ` [PATCH v8 15/16] drm/panfrost: Fix races between perfcnt and reset sequence Adrián Larumbe
2026-09-07 20:36 ` sashiko-bot
2026-09-07 20:16 ` [PATCH v8 16/16] drm/panfrost: Bump driver minor to reflect new DUMP IOCTL req field Adrián Larumbe
2026-09-07 20:33 ` sashiko-bot
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=20260907202818.3B9DF1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=adrian.larumbe@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--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.