linux-kernel - Re: Race condition observed between page migration and page fault handling on arm64 machines

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3b82e195-5871-4880-9ce5-d01bb751f471@redhat.com>
Date: Thu, 1 Aug 2024 10:42:03 +0200
From: David Hildenbrand <david@...hat.com>
To: Dev Jain <dev.jain@....com>, akpm@...ux-foundation.org,
 willy@...radead.org
Cc: ryan.roberts@....com, anshuman.khandual@....com, catalin.marinas@....com,
 cl@...two.org, vbabka@...e.cz, mhocko@...e.com, apopple@...dia.com,
 osalvador@...e.de, baolin.wang@...ux.alibaba.com,
 dave.hansen@...ux.intel.com, will@...nel.org, baohua@...nel.org,
 ioworker0@...il.com, gshan@...hat.com, mark.rutland@....com,
 kirill.shutemov@...ux.intel.com, hughd@...gle.com, aneesh.kumar@...nel.org,
 yang@...amperecomputing.com, peterx@...hat.com, broonie@...nel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org
Subject: Re: Race condition observed between page migration and page fault
 handling on arm64 machines

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

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

-- 
Cheers,

David / dhildenb