From: Philipp Stanner <phasta@mailbox.org>
To: "Maíra Canal" <mcanal@igalia.com>,
"Lucas Stach" <l.stach@pengutronix.de>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Russell King" <linux+etnaviv@armlinux.org.uk>,
"Christian Gmeiner" <cgmeiner@igalia.com>,
"Philipp Stanner" <phasta@kernel.org>
Cc: dri-devel@lists.freedesktop.org, etnaviv@lists.freedesktop.org,
kernel-dev@igalia.com, stable@vger.kernel.org
Subject: Re: [PATCH] drm/etnaviv: Protect the scheduler's pending list with its lock
Date: Mon, 02 Jun 2025 17:33:58 +0200 [thread overview]
Message-ID: <3cb4d2c9c5db4b459344ee1ff6ebdea77804ee4b.camel@mailbox.org> (raw)
In-Reply-To: <20250602132240.93314-1-mcanal@igalia.com>
On Mon, 2025-06-02 at 10:22 -0300, Maíra Canal wrote:
> Commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is
> still
> active") ensured that active jobs are returned to the pending list
> when
> extending the timeout. However, it didn't use the pending list's lock
> to
> manipulate the list, which causes a race condition as the scheduler's
> workqueues are running.
>
> Hold the lock while manipulating the scheduler's pending list to
> prevent
> a race.
>
> Cc: stable@vger.kernel.org
> Fixes: 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is
> still active")
Could also contain a "Closes: " with the link to the appropriate
message from thread [1] from below.
You might also include "Reported-by: Philipp" since I technically first
described the problem. But no hard feelings on that
> Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Philipp Stanner <phasta@kernel.org>
> ---
> Hi,
>
> I'm proposing this workaround patch to address the race-condition
> caused
> by manipulating the pending list without using its lock. Although I
> understand this isn't a complete solution (see [1]), it's not
> reasonable
> to backport the new DRM stat series [2] to the stable branches.
>
> Therefore, I believe the best solution is backporting this fix to the
> stable branches, which will fix the race and will keep adding the job
> back to the pending list (which will avoid most memory leaks).
>
> [1]
> https://lore.kernel.org/dri-devel/bcc0ed477f8a6f3bb06665b1756bcb98fb7af871.camel@mailbox.org/
> [2]
> https://lore.kernel.org/dri-devel/20250530-sched-skip-reset-v2-0-c40a8d2d8daa@igalia.com/
>
> Best Regards,
> - Maíra
> ---
> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> index 76a3a3e517d8..71e2e6b9d713 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> @@ -35,6 +35,7 @@ static enum drm_gpu_sched_stat
> etnaviv_sched_timedout_job(struct drm_sched_job
>
> *sched_job)
> {
> struct etnaviv_gem_submit *submit =
> to_etnaviv_submit(sched_job);
> + struct drm_gpu_scheduler *sched = sched_job->sched;
> struct etnaviv_gpu *gpu = submit->gpu;
> u32 dma_addr, primid = 0;
> int change;
> @@ -89,7 +90,9 @@ static enum drm_gpu_sched_stat
> etnaviv_sched_timedout_job(struct drm_sched_job
> return DRM_GPU_SCHED_STAT_NOMINAL;
>
> out_no_timeout:
> - list_add(&sched_job->list, &sched_job->sched->pending_list);
> + spin_lock(&sched->job_list_lock);
> + list_add(&sched_job->list, &sched->pending_list);
> + spin_unlock(&sched->job_list_lock);
> return DRM_GPU_SCHED_STAT_NOMINAL;
> }
>
next prev parent reply other threads:[~2025-06-02 15:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-02 13:22 [PATCH] drm/etnaviv: Protect the scheduler's pending list with its lock Maíra Canal
2025-06-02 15:33 ` Philipp Stanner [this message]
2025-06-16 14:06 ` Lucas Stach
2025-06-16 23:41 ` Maíra Canal
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=3cb4d2c9c5db4b459344ee1ff6ebdea77804ee4b.camel@mailbox.org \
--to=phasta@mailbox.org \
--cc=cgmeiner@igalia.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=etnaviv@lists.freedesktop.org \
--cc=kernel-dev@igalia.com \
--cc=l.stach@pengutronix.de \
--cc=linux+etnaviv@armlinux.org.uk \
--cc=mcanal@igalia.com \
--cc=p.zabel@pengutronix.de \
--cc=phasta@kernel.org \
--cc=stable@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).