Re: [PATCH v2 2/3] drm/panthor: Revisit reqs_lock handling in flush/reset paths
Boris Brezillon <[email protected]> Mon, 3 Aug 2026 10:53:24 +0200
| Newsgroups | org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel |
|---|---|
| Organization | Collabora |
| Message-ID | <[email protected]> |
Hello Nicolas, On Thu, 30 Jul 2026 13:45:15 +0200 Nicolas Frattaroli <[email protected]> wrote: > panthor_gpu_flush_caches() and panthor_gpu_soft_reset() would read (and > even reset) the contents of the pending_reqs register outside of holding > the reqs_lock. Can you elaborate a bit on the race being fixed here? If pending_reqs bits are truly cleared before the wake_up_all() call (which would require a WRITE_ONCE() to be enforced, admittedly), there's no risk for the wait_event() call to do a test before the bits have been updated, and this holds even if the test is done without the lock held. The other race I could think of is two threads calling panthor_gpu_flush_caches() concurrently, and the second one stealing the FLUSH_COMPLETED event the first thread waits on and re-issuing a second flush on top, thus delaying the completion for the first thread. But that should be covered by the cache_flush_lock. > Additionally, when it did hold the lock, it did so with > the irqsave/irqrestore variants, even though the spinlock was never > acquired in an atomic context, just the threaded handler. > > Use the new wait_event_lock_timeout() macro to check pending_reqs under > the lock, and only do so without disabling interrupts. > > Fixes: 5cd894e258c4 ("drm/panthor: Add the GPU logical block") > Signed-off-by: Nicolas Frattaroli <[email protected]> > --- > drivers/gpu/drm/panthor/panthor_gpu.c | 25 +++++++++++-------------- > 1 file changed, 11 insertions(+), 14 deletions(-) > > diff --git a/drivers/gpu/drm/panthor/panthor_gpu.c b/drivers/gpu/drm/panthor/panthor_gpu.c > index c013d6bf9a59..f015bde80abf 100644 > --- a/drivers/gpu/drm/panthor/panthor_gpu.c > +++ b/drivers/gpu/drm/panthor/panthor_gpu.c > @@ -330,35 +330,34 @@ int panthor_gpu_flush_caches(struct panthor_device *ptdev, > u32 l2, u32 lsc, u32 other) > { > struct panthor_gpu *gpu = ptdev->gpu; > - unsigned long flags; > int ret = 0; > > /* Serialize cache flush operations. */ > guard(mutex)(&ptdev->gpu->cache_flush_lock); > > - spin_lock_irqsave(&ptdev->gpu->reqs_lock, flags); > + spin_lock(&ptdev->gpu->reqs_lock); Can we make the _irq{save,restore}-drop its own patch? > if (!(ptdev->gpu->pending_reqs & GPU_IRQ_CLEAN_CACHES_COMPLETED)) { > ptdev->gpu->pending_reqs |= GPU_IRQ_CLEAN_CACHES_COMPLETED; > gpu_write(gpu->iomem, GPU_CMD, GPU_FLUSH_CACHES(l2, lsc, other)); > } else { > ret = -EIO; > } > - spin_unlock_irqrestore(&ptdev->gpu->reqs_lock, flags); > > - if (ret) > + if (ret) { > + spin_unlock(&ptdev->gpu->reqs_lock); > return ret; > + } > > - if (!wait_event_timeout(ptdev->gpu->reqs_acked, > + if (!wait_event_lock_timeout(ptdev->gpu->reqs_acked, > !(ptdev->gpu->pending_reqs & GPU_IRQ_CLEAN_CACHES_COMPLETED), Assuming we really need to do the test with the lock held, could we add a patch at the beginning of the series that fixes the race without depending on the new wait macro, so that we have a version that can easily be backported? > - msecs_to_jiffies(100))) { > - spin_lock_irqsave(&ptdev->gpu->reqs_lock, flags); > + ptdev->gpu->reqs_lock, msecs_to_jiffies(100))) { > if ((ptdev->gpu->pending_reqs & GPU_IRQ_CLEAN_CACHES_COMPLETED) != 0 && > !(gpu_read(gpu->irq.iomem, INT_RAWSTAT) & GPU_IRQ_CLEAN_CACHES_COMPLETED)) > ret = -ETIMEDOUT; > else > ptdev->gpu->pending_reqs &= ~GPU_IRQ_CLEAN_CACHES_COMPLETED; > - spin_unlock_irqrestore(&ptdev->gpu->reqs_lock, flags); > } > + spin_unlock(&ptdev->gpu->reqs_lock); I think a scoped_guard() could make things a bit cleaner, and given you already turn the regular lock/unlock sequence into a guard in panthor_gpu_soft_reset(), I'd do that here as well. Regards, Boris [1]https://elixir.bootlin.com/linux/v7.2-rc5/source/drivers/gpu/drm/panthor/panthor_gpu.c#L114