From: Tvrtko Ursulin <tursulin@ursulin.net>
To: "Philipp Stanner" <phasta@kernel.org>,
"Matthew Brost" <matthew.brost@intel.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/sched: Mandate usage of drm_sched_job_cleanup()
Date: Mon, 13 Oct 2025 13:20:15 +0100 [thread overview]
Message-ID: <1490c292-c244-4dd9-80a6-3fecd0ffb422@ursulin.net> (raw)
In-Reply-To: <20250926123630.200920-2-phasta@kernel.org>
On 26/09/2025 13:36, Philipp Stanner wrote:
> drm_sched_job_cleanup()'s documentation so far uses relatively soft
> language, only "recommending" usage of the function. To avoid memory
> leaks and, potentiall, other bugs, however, the function has to be used.
>
> Demand usage of the function explicitly.
>
> Signed-off-by: Philipp Stanner <phasta@kernel.org>
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
> index 46119aacb809..0a9df9e61963 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -1030,7 +1030,7 @@ EXPORT_SYMBOL(drm_sched_job_has_dependency);
> *
> * Cleans up the resources allocated with drm_sched_job_init().
> *
> - * Drivers should call this from their error unwind code if @job is aborted
> + * Drivers need to call this from their error unwind code if @job is aborted
Should is indeed wrong. I think it could be better to go with "shall" or
"must" though. Since those two are more standard language for this.
> * before drm_sched_job_arm() is called.
> *
> * drm_sched_job_arm() is a point of no return since it initializes the fences
> @@ -1038,7 +1038,7 @@ EXPORT_SYMBOL(drm_sched_job_has_dependency);
> * submit it with drm_sched_entity_push_job() and cannot simply abort it by
> * calling drm_sched_job_cleanup().
> *
> - * This function should be called in the &drm_sched_backend_ops.free_job callback.
> + * This function must be called in the &drm_sched_backend_ops.free_job callback.
> */
> void drm_sched_job_cleanup(struct drm_sched_job *job)
> {
Hm, having read the thread so far the situation seems not so easy to
untangle.
On one hand I see Matt's point that free_job callback is a bit
misleadingly named and that there isn't anything really requiring
drm_sched_job_cleanup() to be called exactly from there. Free_job
semantics seem to be "job is done, *scheduler* is done with it".
Drm_sched_job_cleanup() already says it has to be called after the point
of no return (arm) so it could be left at drivers discretion (de facto
state today) to choose how and when to do it.
What I did not get is what is actually the perceived problem with
letting this stay? (Ie. "should" indicating it is recommended, but not a
must/shall.)
Regards,
Tvrtko
next prev parent reply other threads:[~2025-10-13 12:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-26 12:36 Philipp Stanner
2025-09-29 17:12 ` Matthew Brost
2025-09-29 17:23 ` Matthew Brost
2025-10-10 8:51 ` Philipp Stanner
2025-10-13 12:20 ` Tvrtko Ursulin [this message]
2025-10-14 11:56 ` Philipp Stanner
2025-10-14 12:05 ` Tvrtko Ursulin
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=1490c292-c244-4dd9-80a6-3fecd0ffb422@ursulin.net \
--to=tursulin@ursulin.net \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.brost@intel.com \
--cc=phasta@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
all inboxes | Powered by JetHome®