Re: [PATCH v4 13/18] drm/panthor: Complain if the SOFT_RESET fails

[Boris Brezillon]

On Fri, 11 Sep 2026 04:40:01 +0100
Adrian Larumbe <adrian.larumbe@xxxxxxxxxxxxx> wrote:

> 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@xxxxxxxxxxxxx>
> > ---
> >  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.

That's what I had in earlier versions of this patchset, and I decided
to get rid of it after discussing it with Liviu and Steve: if a
SOFT_RESET can fail and there's nothing above it to guarantee that the
HW is off and can't do any access to the memory it knew about, we're
just screwed, because then we have to leak resources at unplug time. I
tried it, and it's nasty, so in v4 (or v3, I don't remember) I got back
to something simpler, with the assumption that SOFT_RESET will never
fail (which seems to be the case in practice by the way).