From: Adrian Larumbe <adrian.larumbe@collabora.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Steven Price <steven.price@arm.com>,
Liviu Dudau <liviu.dudau@arm.com>,
Chris Diamand <chris.diamand@arm.com>,
Akash Goel <akash.goel@arm.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>,
Simona Vetter <simona@ffwll.ch>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 13/18] drm/panthor: Complain if the SOFT_RESET fails
Date: Fri, 11 Sep 2026 04:40:01 +0100 [thread overview]
Message-ID: <aqNsLgZRLw_el4h4@sobremesa> (raw)
In-Reply-To: <20260826-panthor-unplug-fixes-v4-13-982cc8f4234b@collabora.com>
On 26.08.2026 16:56, Boris Brezillon wrote:
> We rely on a functioning SOFT_RESET to avoid HW UAFs when the GPU was
> in a state where AS commands were no longer accepted. If we silently
> ignore RESET failures, we're just pretending to be safe while exposing
> ourselves to the very UAFs we were trying to avoid. On the other hand,
> there's basically nothing we can do if both the SOFT_RESET and the
> AS_COMMAND(UNMAPPED) fail, so do what we do best: complain loudly and
> taint the kernel with a WARN_ON().
>
> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
> ---
> drivers/gpu/drm/panthor/panthor_hw.h | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_hw.h b/drivers/gpu/drm/panthor/panthor_hw.h
> index 4531c1239cb6..f13fd7b335c1 100644
> --- a/drivers/gpu/drm/panthor/panthor_hw.h
> +++ b/drivers/gpu/drm/panthor/panthor_hw.h
> @@ -41,9 +41,17 @@ int panthor_hw_init(struct panthor_device *ptdev);
> int panthor_hw_power_status_register(void);
> void panthor_hw_power_status_unregister(void);
>
> -static inline int panthor_hw_soft_reset(struct panthor_device *ptdev)
> +static inline void
> +panthor_hw_soft_reset(struct panthor_device *ptdev)
> {
> - return ptdev->hw->ops.soft_reset(ptdev);
> + /* We're relying on the SOFT_RESET to reset the MMU block if some AS
> + * were stuck for some reason. Failing to reset the MMU/L2 means we're
> + * exposing ourselves to HW UAFs. On the other hand, there's basically
> + * nothing we can do if both the SOFT_RESET and
> + * the AS_COMMAND(UNMAPPED) fail, so do what we do best: complain loudly
> + * and taint the kernel.
> + */
> + drm_WARN_ON(&ptdev->base, ptdev->hw->ops.soft_reset(ptdev));
I think you forgot to include drm/drm_print.h, although Sashiko probably picked up on this.
On top of that, I wonder if failure to soft reset should be carried up the call stack and
eventually lead to an early unplug, just like you do when panthor_fw_post_reset() fails.
> }
>
> static inline int panthor_hw_l2_power_on(struct panthor_device *ptdev)
>
> --
> 2.55.0
Adrian Larumbe
next prev parent reply other threads:[~2026-09-11 3:40 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 14:55 [PATCH v4 00/18] drm/panthor: Fix the unplug logic Boris Brezillon
2026-08-26 14:56 ` [PATCH v4 01/18] drm/panthor: Disable reset work before unplug Boris Brezillon
2026-08-27 13:00 ` Liviu Dudau
2026-09-10 1:12 ` Adrian Larumbe
2026-08-26 14:56 ` [PATCH v4 02/18] drm/panthor: Revisit the reset logic to avoid reset request loss Boris Brezillon
2026-08-27 15:04 ` Liviu Dudau
2026-09-10 1:13 ` Adrian Larumbe
2026-08-26 14:56 ` [PATCH v4 03/18] drm/panthor: Make panthor_device::pm::state non-atomic Boris Brezillon
2026-08-27 15:12 ` Liviu Dudau
2026-09-10 1:13 ` Adrian Larumbe
2026-08-26 14:56 ` [PATCH v4 04/18] drm/panthor: Flush the cleanup_wq in the unplug path Boris Brezillon
2026-08-27 15:14 ` Liviu Dudau
2026-09-10 1:14 ` Adrian Larumbe
2026-08-26 14:56 ` [PATCH v4 05/18] drm/panthor: Make the page table cache and cleanup workqueue device-local Boris Brezillon
2026-08-27 15:20 ` Liviu Dudau
2026-09-10 1:14 ` Adrian Larumbe
2026-08-26 14:56 ` [PATCH v4 06/18] drm/panthor: Drop unused vm argument passed to panthor_vm_prepare_sync_only_op_ctx() Boris Brezillon
2026-08-27 15:21 ` Liviu Dudau
2026-09-10 1:15 ` Adrian Larumbe
2026-08-26 14:56 ` [PATCH v4 07/18] drm/panthor: Move the debugfs initialization to panthor_device.c Boris Brezillon
2026-09-10 1:18 ` Adrian Larumbe
2026-08-26 14:56 ` [PATCH v4 08/18] drm/panthor: Split panthor_vm Boris Brezillon
2026-09-11 3:37 ` Adrian Larumbe
2026-09-11 9:48 ` Boris Brezillon
2026-09-11 22:55 ` Adrian Larumbe
2026-08-26 14:56 ` [PATCH v4 09/18] drm/panthor: Add fine-grained restrictions on VMs Boris Brezillon
2026-09-11 3:38 ` Adrian Larumbe
2026-08-26 14:56 ` [PATCH v4 10/18] drm/panthor: Check AS state before disabling Boris Brezillon
2026-09-11 3:38 ` Adrian Larumbe
2026-08-26 14:56 ` [PATCH v4 11/18] drm/panthor: Don't pre-allocate VMAs or page tables when preparing a full VM unmap Boris Brezillon
2026-09-11 3:38 ` Adrian Larumbe
2026-08-26 14:56 ` [PATCH v4 12/18] drm/panthor: Let l2_power_off return errors and force users to check it Boris Brezillon
2026-09-11 3:39 ` Adrian Larumbe
2026-08-26 14:56 ` [PATCH v4 13/18] drm/panthor: Complain if the SOFT_RESET fails Boris Brezillon
2026-09-11 3:40 ` Adrian Larumbe [this message]
2026-09-11 9:54 ` Boris Brezillon
2026-08-26 14:56 ` [PATCH v4 14/18] drm/panthor: Make the VM cleanup path more robust against UAF Boris Brezillon
2026-09-11 19:15 ` Adrian Larumbe
2026-08-26 14:56 ` [PATCH v4 15/18] drm/panthor: Track user owned VMs Boris Brezillon
2026-09-11 19:17 ` Adrian Larumbe
2026-08-26 14:56 ` [PATCH v4 16/18] drm/panthor: Track user owned groups Boris Brezillon
2026-09-11 19:17 ` Adrian Larumbe
2026-08-26 14:56 ` [PATCH v4 17/18] drm/panthor: Fix the unplug logic Boris Brezillon
2026-09-11 22:44 ` Adrian Larumbe
2026-08-26 14:56 ` [PATCH v4 18/18] drm/panthor: Add debugfs knobs to simulate reset failures Boris Brezillon
2026-09-11 19:18 ` Adrian Larumbe
2026-09-12 19:27 ` Adrian Larumbe
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=aqNsLgZRLw_el4h4@sobremesa \
--to=adrian.larumbe@collabora.com \
--cc=airlied@gmail.com \
--cc=akash.goel@arm.com \
--cc=boris.brezillon@collabora.com \
--cc=chris.diamand@arm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--cc=tzimmermann@suse.de \
/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.