All of lore.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2026-09-10  8:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10  5:46 drm/sched: run queues freed before the TDR that drm_sched_fini() waits for 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
  -- strict thread matches above, loose matches on Subject: below --
2026-09-10  5:12 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.