amd-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Felix Kuehling <felix.kuehling@amd.com>
To: philip yang <yangp@amd.com>,
	amd-gfx@lists.freedesktop.org, Alex Sierra <alex.sierra@amd.com>,
	"Yang, Philip" <Philip.Yang@amd.com>
Subject: Re: [PATCH] drm/amdkfd: svm ranges creation for unregistered memory
Date: Thu, 22 Apr 2021 09:20:33 -0400	[thread overview]
Message-ID: <5a0dcda1-e270-c109-cfb2-eb882bda0507@amd.com> (raw)
In-Reply-To: <13fd91b6-473a-984f-6678-b3e3af613e0d@amd.com>

Am 2021-04-22 um 9:08 a.m. schrieb philip yang:
>
>
> On 2021-04-20 9:25 p.m., Felix Kuehling wrote:
> @@ -2251,14 +2330,34 @@ svm_range_restore_pages(struct amdgpu_device
> *adev, unsigned int pasid,
>>>>  	}
>>>>  
>>>>  	mmap_read_lock(mm);
>>>> +retry_write_locked:
>>>>  	mutex_lock(&svms->lock);
>>>>  	prange = svm_range_from_addr(svms, addr, NULL);
>>>>  	if (!prange) {
>>>>  		pr_debug("failed to find prange svms 0x%p address [0x%llx]\n",
>>>>  			 svms, addr);
>>>> -		r = -EFAULT;
>>>> -		goto out_unlock_svms;
>>>> +		if (!write_locked) {
>>>> +			/* Need the write lock to create new range with MMU notifier.
>>>> +			 * Also flush pending deferred work to make sure the interval
>>>> +			 * tree is up to date before we add a new range
>>>> +			 */
>>>> +			mutex_unlock(&svms->lock);
>>>> +			mmap_read_unlock(mm);
>>>> +			svm_range_list_lock_and_flush_work(svms, mm);
>> I think this can deadlock with a deferred worker trying to drain
>> interrupts (Philip's patch series). If we cannot flush deferred work
>> here, we need to be more careful creating new ranges to make sure they
>> don't conflict with added deferred or child ranges.
>
> It's impossible to have deadlock with deferred worker to drain
> interrupts, because drain interrupt wait for restore_pages without
> taking any lock, and restore_pages flush deferred work without taking
> any lock too.
>
The deadlock does not come from holding or waiting for locks. It comes
from the worker waiting for interrupts to drain and the interrupt
handler waiting for the worker to finish with flush_work in
svm_range_list_lock_and_flush_work. If both are waiting for each other,
neither can make progress and you have a deadlock.

Regards,
  Felix


> Regards,
>
> Philip
>
>> Regards,
>>   Felix
>>
>>
>>>> +			write_locked = true;
>>>> +			goto retry_write_locked;
>>>> +		}
>>>> +		prange = svm_range_create_unregistered_range(adev, p, mm, addr);
>>>> +		if (!prange) {
>>>> +			pr_debug("failed to create unregisterd range svms 0x%p address [0x%llx]\n",
>>>> +			svms, addr);
>>>> +			mmap_write_downgrade(mm);
>>>> +			r = -EFAULT;
>>>> +			goto out_unlock_svms;
>>>> +		}
>>>>  	}
>>>> +	if (write_locked)
>>>> +		mmap_write_downgrade(mm);
>>>>  
>>>>  	mutex_lock(&prange->migrate_mutex);
>>>>  
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  reply	other threads:[~2021-04-22 13:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-20  1:52 [PATCH] drm/amdkfd: svm ranges creation for unregistered memory Alex Sierra
2021-04-21  0:16 ` philip yang
2021-04-21  0:45 ` Felix Kuehling
2021-04-21  1:25   ` Felix Kuehling
2021-04-22 13:08     ` philip yang
2021-04-22 13:20       ` Felix Kuehling [this message]
2021-04-22 15:16         ` philip yang
  -- strict thread matches above, loose matches on Subject: below --
2021-04-22 14:47 Alex Sierra
2021-04-22 15:31 ` Felix Kuehling
2021-04-19 17:24 Alex Sierra
2021-04-19 20:34 ` Felix Kuehling

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=5a0dcda1-e270-c109-cfb2-eb882bda0507@amd.com \
    --to=felix.kuehling@amd.com \
    --cc=Philip.Yang@amd.com \
    --cc=alex.sierra@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=yangp@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 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).