linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Dev Jain <dev.jain@arm.com>,
	akpm@linux-foundation.org, willy@infradead.org
Cc: ryan.roberts@arm.com, anshuman.khandual@arm.com,
	catalin.marinas@arm.com, cl@gentwo.org, vbabka@suse.cz,
	mhocko@suse.com, apopple@nvidia.com, osalvador@suse.de,
	baolin.wang@linux.alibaba.com, dave.hansen@linux.intel.com,
	will@kernel.org, baohua@kernel.org, ioworker0@gmail.com,
	gshan@redhat.com, mark.rutland@arm.com,
	kirill.shutemov@linux.intel.com, hughd@google.com,
	aneesh.kumar@kernel.org, yang@os.amperecomputing.com,
	peterx@redhat.com, broonie@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: Race condition observed between page migration and page fault handling on arm64 machines
Date: Thu, 1 Aug 2024 11:41:04 +0200	[thread overview]
Message-ID: <a6a38ad5-c754-44ad-a64b-f9ea5b764291@redhat.com> (raw)
In-Reply-To: <bbe411f2-4c68-4f92-af8c-da184669dca8@arm.com>

On 01.08.24 11:38, Dev Jain wrote:
> 
> On 8/1/24 14:12, David Hildenbrand wrote:
>> On 01.08.24 10:16, Dev Jain wrote:
>>> I and Ryan had a discussion and we thought it would be best to get
>>> feedback
>>> from the community.
>>>
>>> The migration mm selftest currently fails on arm64 for shared anon
>>> mappings,
>>> due to the following race:
>>
>> Do you mean MAP_SHARED|MAP_ANON or MAP_PRIVATE|MAP_ANON_fork? Because
>> you note shmem below, I assume you mean MAP_SHARED|MAP_ANON
> 
> 
> Yes.
> 
>>
>>>
>>> Migration:                        Page fault:
>>> try_to_migrate_one():                    handle_pte_fault():
>>> 1. Nuke the PTE                        PTE has been deleted =>
>>> do_pte_missing()
>>> 2. Mark the PTE for migration                PTE has not been deleted
>>> but is just not "present" => do_swap_page()
>>>
>>
>> In filemap_fault_recheck_pte_none() we recheck under PTL to make sure
>> that a temporary pte_none() really was persistent pte_none() and not a
>> temporary pte_none() under PTL.
>>
>> Should we do something similar in do_fault()? I see that we already do
>> something like that on the "!vma->vm_ops->fault" path.
>>
>> But of course, there is a tradeoff between letting migration
>> (temporarily) fail and grabbing the PTL during page faults.
> 
> 
> To dampen the tradeoff, we could do this in shmem_fault() instead? But
> then, this would mean that we do this in all
> 
> kinds of vma->vm_ops->fault, only when we discover another reference
> count race condition :) Doing this in do_fault()
> 
> should solve this once and for all. In fact, do_pte_missing() may call
> do_anonymous_page() or do_fault(), and I just
> 
> noticed that the former already checks this using vmf_pte_changed().

What I am still missing is why this is (a) arm64 only; and (b) if this 
is something we should really worry about. There are other reasons 
(e.g., speculative references) why migration could temporarily fail, 
does it happen that often that it is really something we have to worry 
about?

-- 
Cheers,

David / dhildenb



  reply	other threads:[~2024-08-01  9:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-01  8:16 Race condition observed between page migration and page fault handling on arm64 machines Dev Jain
2024-08-01  8:42 ` David Hildenbrand
2024-08-01  9:38   ` Dev Jain
2024-08-01  9:41     ` David Hildenbrand [this message]
2024-08-01 10:05       ` Dev Jain
2024-08-01 13:13         ` David Hildenbrand
2024-08-01 13:26           ` David Hildenbrand
2024-08-01 13:43             ` Will Deacon
2024-08-01 13:48               ` David Hildenbrand
2024-08-01 14:25                 ` Ryan Roberts
2024-08-05  9:51                 ` Dev Jain
2024-08-05 10:46                   ` David Hildenbrand
2024-08-05 14:14                     ` Dev Jain
     [not found]                       ` <a8c813b5-abce-48cf-9d14-2f969d6c8180@redhat.com>
     [not found]                         ` <8158c9d6-cbfe-4767-be8e-dc227b29200c@arm.com>
2024-08-09 13:23                           ` David Hildenbrand
2024-08-09 13:26                             ` David Hildenbrand
2024-08-01 10:06       ` Ryan Roberts
2024-08-01 13:15         ` David Hildenbrand

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=a6a38ad5-c754-44ad-a64b-f9ea5b764291@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@kernel.org \
    --cc=anshuman.khandual@arm.com \
    --cc=apopple@nvidia.com \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=cl@gentwo.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=dev.jain@arm.com \
    --cc=gshan@redhat.com \
    --cc=hughd@google.com \
    --cc=ioworker0@gmail.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=mhocko@suse.com \
    --cc=osalvador@suse.de \
    --cc=peterx@redhat.com \
    --cc=ryan.roberts@arm.com \
    --cc=vbabka@suse.cz \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    --cc=yang@os.amperecomputing.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).