From: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
To: "Christian König" <christian.koenig@amd.com>, phasta@kernel.org
Cc: Donggeun Yoo <donggeunyoo.kernel@gmail.com>,
Philipp Stanner <phasta@mailbox.org>,
Tvrtko Ursulin <tvrtko.ursulin@igalia.com>,
Luben Tuikov <ltuikov89@gmail.com>,
Matthew Brost <matthew.brost@intel.com>,
Danilo Krummrich <dakr@kernel.org>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: drm/sched: run queues freed before the TDR that drm_sched_fini() waits for
Date: Thu, 10 Sep 2026 17:44:08 +0900 [thread overview]
Message-ID: <20260910084408.703333-1-donggeunyoo.kernel@gmail.com> (raw)
In-Reply-To: <df7b0d1e-5a74-445b-90fe-fae30cee4cb3@amd.com>
On 9/10/26 09:32, Christian König wrote:
> Amdgpu shouldn't do that any more.
Correct, and I should have checked before writing it - 182bdd59be41
("drm/amdgpu: deprecate guilty handling") removed it. The callers left are
etnaviv, lima, panfrost and v3d. v3d is the one I should have named.
> That was an extremely ugly hack applied long long time ago because amdgpu
> was broken at that time and didn't waited for
> drm_sched_entity_flush()/drm_sched_entity_fini() before calling
> drm_sched_fini().
Understood, I am dropping that half of the argument.
> No it doesn't. You quoted the wrong code, this is what really matters:
>
> drm_sched_wqueue_stop(sched);
>
> for (i = DRM_SCHED_PRIORITY_KERNEL; i < sched->num_rqs; i++)
> kfree(sched->sched_rq[i]);
I am not sure I follow this one. If the point is that
drm_sched_wqueue_stop() has already quiesced the users of the run queues
by the time the loop runs, I cannot find where it covers the timeout work:
WRITE_ONCE(sched->pause_submit, true);
cancel_work_sync(&sched->work_run_job);
cancel_work_sync(&sched->work_free_job);
work_tdr is queued on sched->timeout_wq and is only canceled by the
cancel_delayed_work_sync() below the loop, so a timeout handler can still
be running while the run queues are freed. Is there something else that
rules that out? And if I have misread your point, please elaborate.
On how I got there: the KUnit case never signals the hardware fence, which
is what keeps the handler inside timedout_job() while drm_sched_fini() runs.
That breaks the rule that all run_job() fences are signaled before
drm_sched_fini(), so a correct driver should not reach this, and I have no
reproducer that does not cheat that way. The same caveat is in the patch.
I am writing up the patch Philipp asked for. The only change is moving the
kfree loop down beside kfree(sched->sched_rq); no new code.
Regards,
Donggeun
next prev parent reply other threads:[~2026-09-10 8:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 5:46 Donggeun Yoo
2026-09-10 6:52 ` Philipp Stanner
2026-09-10 7:04 ` Philipp Stanner
2026-09-10 7:32 ` Christian König
2026-09-10 8:44 ` Donggeun Yoo [this message]
2026-09-10 8:51 ` Philipp Stanner
2026-09-10 9:50 ` Donggeun Yoo
2026-09-10 11:04 ` Philipp Stanner
2026-09-10 13:58 ` Christian König
2026-09-12 1:48 ` Donggeun Yoo
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=20260910084408.703333-1-donggeunyoo.kernel@gmail.com \
--to=donggeunyoo.kernel@gmail.com \
--cc=christian.koenig@amd.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltuikov89@gmail.com \
--cc=matthew.brost@intel.com \
--cc=phasta@kernel.org \
--cc=phasta@mailbox.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
all inboxes | Powered by JetHome®