All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Khatri, Sunil" <sukhatri@amd.com>
To: "Christian König" <christian.koenig@amd.com>,
	"Sunil Khatri" <sunil.khatri@amd.com>,
	"Alex Deucher" <alexander.deucher@amd.com>
Cc: dri-devel@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [PATCH v2] drm/drm_exec: fix contention when num_objects is 0
Date: Tue, 8 Sep 2026 19:34:58 +0530	[thread overview]
Message-ID: <daf90404-9aa1-4f86-ac41-bf6e28446b08@amd.com> (raw)
In-Reply-To: <1081fa83-d2f7-40be-816d-29f28c6e7576@amd.com>


On 08-09-2026 07:26 pm, Christian König wrote:
> On 9/8/26 11:17, Sunil Khatri wrote:
>> drm_exec_prepare_array() silently returns success without calling
>> drm_exec_lock_contended() when num_objects is zero. This breaks the
>> invariant upheld by drm_exec_lock_obj(), where every entry point into
>> the locking sequence must first attempt to lock any previously
>> contended object before proceeding.
>>
>> Drivers that chain multiple drm_exec_prepare_array() calls per
>> drm_exec_until_all_locked() iteration (e.g. amdgpu's userq signal/wait
>> ioctls, which prepare separate read and write BO arrays) can pass an
>> empty array for one of the two calls. If contention is hit while
>> preparing the non-empty array, exec->contended is set and the loop
>> retries; on retry, the empty-array call preceding it is a no-op that
>> never clears exec->contended, so drm_exec_retry_on_contention()
>> immediately jumps back to the top of the loop without ever reaching
>> the call that would resolve the contention. This spins forever.
>>
>> Fix it by having drm_exec_prepare_array() call drm_exec_lock_contended()
>> directly when num_objects is zero, so a pending contended object dont
>> loop infinitely.
>>
>> Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7")
>> CC: stable@vger.kernel.org
> I've added a # v6.6+ here.
>
> BTW: If you identified the commit you can use "git tag --contains=09593216bff1" to figure that out.
Sure thanks.  So the first tag when the change is introduced to be used 
which here is v6.6.
Thanks for the tag command.
>
>> Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
> Reviewed-by: Christian König <christian.koenig@amd.com>
>
> I'm going to push this to drm-misc-fixes, please sync with Alex to get that cherry picked into amd-staging-drm-next as well.

Sure once i fine it in drm-misc-fixes i will sync with alex to 
cherry-pick it into amd-staging-drm-next.

Thanks
Sunil Khatri

>
> Thanks,
> Christian.
>
>> ---
>>   drivers/gpu/drm/drm_exec.c | 13 +++++++++++++
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_exec.c b/drivers/gpu/drm/drm_exec.c
>> index fa923852fae4..f4503ab82c66 100644
>> --- a/drivers/gpu/drm/drm_exec.c
>> +++ b/drivers/gpu/drm/drm_exec.c
>> @@ -322,6 +322,19 @@ int drm_exec_prepare_array(struct drm_exec *exec,
>>   {
>>   	int ret;
>>   
>> +	/*
>> +	 * Make sure to lock a contended object even when no objects are
>> +	 * given, otherwise drm_exec_retry_on_contention() would loop
>> +	 * forever on patterns like:
>> +	 *
>> +	 *	ret = drm_exec_prepare_array(exec, objs, num_objects, ...);
>> +	 *	drm_exec_retry_on_contention(exec);
>> +	 *
>> +	 * with num_objects == 0.
>> +	 */
>> +	if (!num_objects)
>> +		return drm_exec_lock_contended(exec);
>> +
>>   	for (unsigned int i = 0; i < num_objects; ++i) {
>>   		ret = drm_exec_prepare_obj(exec, objects[i], num_fences);
>>   		if (unlikely(ret))

      reply	other threads:[~2026-09-08 14:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260908091729.2749399-1-sunil.khatri@amd.com>
2026-09-08 13:56 ` [PATCH v2] drm/drm_exec: fix contention when num_objects is 0 Christian König
2026-09-08 14:04   ` Khatri, Sunil [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=daf90404-9aa1-4f86-ac41-bf6e28446b08@amd.com \
    --to=sukhatri@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=stable@vger.kernel.org \
    --cc=sunil.khatri@amd.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.