From: Philipp Stanner <phasta@mailbox.org>
To: "Tvrtko Ursulin" <tvrtko.ursulin@igalia.com>,
"Philipp Stanner" <phasta@kernel.org>,
"Matthew Brost" <matthew.brost@intel.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-media@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] drm/sched: Fix race in drm_sched_entity_select_rq()
Date: Mon, 27 Oct 2025 13:50:28 +0100 [thread overview]
Message-ID: <19a92d6d0ee730074139a36c38cc2fe16c72c588.camel@mailbox.org> (raw)
In-Reply-To: <26eef700-7997-42e5-b0b9-c03361e05814@igalia.com>
On Wed, 2025-10-22 at 08:16 +0100, Tvrtko Ursulin wrote:
>
> On 22/10/2025 07:34, Philipp Stanner wrote:
> > In a past bug fix it was forgotten that entity access must be protected
> > by the entity lock. That's a data race and potentially UB.
> >
> > Move the spin_unlock() to the appropriate position.
> >
> > Cc: stable@vger.kernel.org # v5.13+
> > Fixes: ac4eb83ab255 ("drm/sched: select new rq even if there is only one v3")
> > Signed-off-by: Philipp Stanner <phasta@kernel.org>
> > ---
> > drivers/gpu/drm/scheduler/sched_entity.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c
> > index 5a4697f636f2..aa222166de58 100644
> > --- a/drivers/gpu/drm/scheduler/sched_entity.c
> > +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> > @@ -552,10 +552,11 @@ void drm_sched_entity_select_rq(struct drm_sched_entity *entity)
> > drm_sched_rq_remove_entity(entity->rq, entity);
> > entity->rq = rq;
> > }
> > - spin_unlock(&entity->lock);
> >
> > if (entity->num_sched_list == 1)
> > entity->sched_list = NULL;
> > +
> > + spin_unlock(&entity->lock);
> > }
> >
> > /**
>
> Agreed, unlock at the end is correct.
>
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Applied to drm-misc-fixes.
Thx
P.
>
> Luckily only amdgpu calls drm_sched_entity_modify_sched(), and I am not
> sure if with hypothetical multi-threaded submit it could be possible to
> hit it or not.
>
> One thread would have to clear the sched_list, while another would have
> to have passed the !sched_list at the beginning of the function, and the
> job_queue count and last_scheduled completed guards. Which would mean
> job has to get completed between the unlock and clearing the pointer.
>
> Also, take a look at this when you can please:
>
> https://lore.kernel.org/dri-devel/20240719094730.55301-1-tursulin@igalia.com/
>
> This would also have fixed this issue by removing clearing of
> entity->sched_list. Latter being just a hack to work around the issue of
> confused container ownership rules.
>
> Regards,
>
> Tvrtko
>
prev parent reply other threads:[~2025-10-27 12:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-22 6:34 [PATCH] drm/sched: Fix race in drm_sched_entity_select_rq() Philipp Stanner
2025-10-22 7:16 ` Tvrtko Ursulin
2025-10-27 12:50 ` Philipp Stanner [this message]
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=19a92d6d0ee730074139a36c38cc2fe16c72c588.camel@mailbox.org \
--to=phasta@mailbox.org \
--cc=airlied@gmail.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=matthew.brost@intel.com \
--cc=phasta@kernel.org \
--cc=simona@ffwll.ch \
--cc=stable@vger.kernel.org \
--cc=tvrtko.ursulin@igalia.com \
/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).