From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA684322B9F for ; Mon, 3 Aug 2026 08:53:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785747222; cv=none; b=UKz/ocTiXFn1bl46IG7eDen5YrAoP0hMS9eAHpEmh5zzZFtJcOwb8YverMwPZUqRB9Tsvs2kU+9ZSm0zwcigabulopNGMwpvSRuy7MAQQMDsFr/OoiLklvGFqnQ8LM6QsuNbLvbqIiCAeROaReCPasCgo5ozRsr7df6Qaic+3tw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785747222; c=relaxed/simple; bh=fHyg4SxQfGroYY8Z6cFPEXyX60KEci0W3NHVSflRpkM=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=CcedCNp/4Td2X1GGxH8+v8mKOQiKcUxsdvLdtOkxIySdaAwYa/Ju0ATR+Yqz1+kBr3yAJL3JtSd3FWpAhdoVsLBZgKyun9igh/xbmownAerEtwfvZZS6zSqCsW6jvvivSnopYQH7lFAX9C91y/ANVCO+c8IYcK2WlM86wkQGL/g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=pN+10Pm6; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="pN+10Pm6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1785747213; bh=fHyg4SxQfGroYY8Z6cFPEXyX60KEci0W3NHVSflRpkM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=pN+10Pm6TqFKpc2wBHFr5/r2dPS4hSEjor/v9NO4FxIMPWJ0W/fYWbVk0m/eDiE+Z CL7+LOI2gMwhtjzTjJQTOx6U0r7A4ez4k5QJiPNrzOux3KfsUZ8cBFav3caolXU3zB oWC996EgxCYavijg0ITAb0IB/p/Z+a3OmMiWWEZPa4kOEd8EQWsvnixTaOrRaI+Zq6 dMF/5tINU+oqqYBAj+9J8N6OUpmUvwDEYD8aupIq1H0IhnvcuykbVSo03msiIoP9+k Vou9IoZXeuVfswwn+n0M8k3nL5ltRKjOKTYupZFaODsu+3BnAub75TI1DN1JMZhzA9 Qwm4EHtSP/5Og== Received: from fedora1.home (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange secp256r1 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id 2E79917E0177; Mon, 03 Aug 2026 10:53:32 +0200 (CEST) Date: Mon, 3 Aug 2026 10:53:24 +0200 From: Boris Brezillon To: Nicolas Frattaroli Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , Steven Price , Liviu Dudau , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Grant Likely , Heiko Stuebner , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, kernel@collabora.com Subject: Re: [PATCH v2 2/3] drm/panthor: Revisit reqs_lock handling in flush/reset paths Message-ID: <20260803105324.478ed594@fedora1.home> In-Reply-To: <20260730-panthor-cache-flush-fix-v2-2-28790478bfff@collabora.com> References: <20260730-panthor-cache-flush-fix-v2-0-28790478bfff@collabora.com> <20260730-panthor-cache-flush-fix-v2-2-28790478bfff@collabora.com> Organization: Collabora X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello Nicolas, On Thu, 30 Jul 2026 13:45:15 +0200 Nicolas Frattaroli 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 > --- > 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