From: "Kuehling, Felix" <Felix.Kuehling@amd.com>
To: Jerome Glisse <jglisse@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: "Deucher, Alexander" <Alexander.Deucher@amd.com>,
"airlied@gmail.com" <airlied@gmail.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 2/2] mm/hmm: Only set FAULT_FLAG_ALLOW_RETRY for non-blocking
Date: Mon, 13 May 2019 20:31:49 +0000 [thread overview]
Message-ID: <af7bdc84-12d5-0e6b-c8cd-469bc8be5667@amd.com> (raw)
In-Reply-To: <20190513194925.GA31365@redhat.com>
[Fixed Alex's email address, sorry for getting it wrong first]
On 2019-05-13 3:49 p.m., Jerome Glisse wrote:
> [CAUTION: External Email]
>
> Andrew can we get this 2 fixes line up for 5.2 ?
>
> On Mon, May 13, 2019 at 07:36:44PM +0000, Kuehling, Felix wrote:
>> Hi Jerome,
>>
>> Do you want me to push the patches to your branch? Or are you going to
>> apply them yourself?
>>
>> Is your hmm-5.2-v3 branch going to make it into Linux 5.2? If so, do you
>> know when? I'd like to coordinate with Dave Airlie so that we can also
>> get that update into a drm-next branch soon.
>>
>> I see that Linus merged Dave's pull request for Linux 5.2, which
>> includes the first changes in amdgpu using HMM. They're currently broken
>> without these two patches.
> HMM patch do not go through any git branch they go through the mmotm
> collection. So it is not something you can easily coordinate with drm
> branch.
>
> By broken i expect you mean that if numabalance happens it breaks ?
> Or it might sleep when you are not expecting it too ?
Without the NUMA fix we'd end up using an outdated physical address in
the GPU page table. The problem was caught by a test that got incorrect
computation results using OpenCL on a NUMA system.
Without the FAULT_FLAG_ALLOW_RETRY patch, there can be kernel oopses due
to incorrect locking/unlocking of mmap_sem. It breaks the promise that
hmm_range_fault should not unlock the mmap_sem if block==true. It takes
some memory pressure to trigger this.
Regards,
Felix
>
> Cheers,
> Jérôme
>
>> Thanks,
>> Felix
>>
>> On 2019-05-10 4:14 p.m., Jerome Glisse wrote:
>>> [CAUTION: External Email]
>>>
>>> On Fri, May 10, 2019 at 07:53:24PM +0000, Kuehling, Felix wrote:
>>>> Don't set this flag by default in hmm_vma_do_fault. It is set
>>>> conditionally just a few lines below. Setting it unconditionally
>>>> can lead to handle_mm_fault doing a non-blocking fault, returning
>>>> -EBUSY and unlocking mmap_sem unexpectedly.
>>>>
>>>> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
>>> Reviewed-by: Jérôme Glisse <jglisse@redhat.com>
>>>
>>>> ---
>>>> mm/hmm.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/mm/hmm.c b/mm/hmm.c
>>>> index b65c27d5c119..3c4f1d62202f 100644
>>>> --- a/mm/hmm.c
>>>> +++ b/mm/hmm.c
>>>> @@ -339,7 +339,7 @@ struct hmm_vma_walk {
>>>> static int hmm_vma_do_fault(struct mm_walk *walk, unsigned long addr,
>>>> bool write_fault, uint64_t *pfn)
>>>> {
>>>> - unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_REMOTE;
>>>> + unsigned int flags = FAULT_FLAG_REMOTE;
>>>> struct hmm_vma_walk *hmm_vma_walk = walk->private;
>>>> struct hmm_range *range = hmm_vma_walk->range;
>>>> struct vm_area_struct *vma = walk->vma;
>>>> --
>>>> 2.17.1
>>>>
next prev parent reply other threads:[~2019-05-13 20:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-10 19:53 [PATCH 0/2] Two bug-fixes for HMM Kuehling, Felix
2019-05-10 19:53 ` [PATCH 1/2] mm/hmm: support automatic NUMA balancing Kuehling, Felix
2019-05-10 20:13 ` Jerome Glisse
2019-05-13 21:27 ` Andrew Morton
2019-05-13 22:37 ` Jerome Glisse
2019-05-14 21:14 ` Kuehling, Felix
2019-05-10 19:53 ` [PATCH 2/2] mm/hmm: Only set FAULT_FLAG_ALLOW_RETRY for non-blocking Kuehling, Felix
2019-05-10 20:14 ` Jerome Glisse
2019-05-13 19:36 ` Kuehling, Felix
2019-05-13 19:49 ` Jerome Glisse
2019-05-13 20:31 ` Kuehling, Felix [this message]
2019-05-13 20:21 ` Deucher, Alexander
2019-05-14 21:12 ` Kuehling, Felix
2019-05-14 21:58 ` Alex Deucher
2019-06-06 15:11 ` [PATCH 0/2] Two bug-fixes for HMM Jason Gunthorpe
2019-06-06 19:04 ` Kuehling, Felix
2019-06-06 19:20 ` Jason Gunthorpe
2019-06-06 19:16 ` Kuehling, Felix
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=af7bdc84-12d5-0e6b-c8cd-469bc8be5667@amd.com \
--to=felix.kuehling@amd.com \
--cc=Alexander.Deucher@amd.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=amd-gfx@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jglisse@redhat.com \
--cc=linux-mm@kvack.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;
as well as URLs for NNTP newsgroup(s).