linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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
>>>>

  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).