linux-kernel - Re: [PATCH v1 5/7] mm: pgtable: try to reclaim empty PTE page in madvise(MADV

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: <32c14642-462d-4b29-bcf2-997c068d0f59@bytedance.com>
Date: Fri, 18 Oct 2024 10:58:39 +0800
From: Qi Zheng <zhengqi.arch@...edance.com>
To: Jann Horn <jannh@...gle.com>
Cc: Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
 david@...hat.com, hughd@...gle.com, willy@...radead.org, mgorman@...e.de,
 muchun.song@...ux.dev, vbabka@...nel.org, akpm@...ux-foundation.org,
 zokeefe@...gle.com, rientjes@...gle.com, peterx@...hat.com,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH v1 5/7] mm: pgtable: try to reclaim empty PTE page in
 madvise(MADV_DONTNEED)



On 2024/10/18 10:53, Qi Zheng wrote:
> 
> 
> On 2024/10/18 02:43, Jann Horn wrote:
>> +arm64 maintainers in case they have opinions on the break-before-make 
>> aspects
>>

[snip]

>>> +
>>> +       pmd_clear(pmd);
>>> +
>>> +       if (ptl != pml)
>>> +               spin_unlock(ptl);
>>> +       spin_unlock(pml);
>>
>> At this point, you have cleared the PMD and dropped the locks
>> protecting against concurrency, but have not yet done a TLB flush. If
>> another thread concurrently repopulates the PMD at this point, can we
>> get incoherent TLB state in a way that violates the arm64
>> break-before-make rule?
>>
>> Though I guess we can probably already violate break-before-make if
>> MADV_DONTNEED races with a pagefault, since zap_present_folio_ptes()
>> does not seem to set "force_flush" when zapping anon PTEs...
> 
> Thanks for pointing this out! That's why I sent a separate patch
> discussing this a while ago, but unfortunately haven't gotten any
> feedback yet, please take a look:
> 
> https://lore.kernel.org/lkml/20240815120715.14516-1-zhengqi.arch@bytedance.com/

More context here: 
https://lore.kernel.org/lkml/6f38cb19-9847-4f70-bbe7-06881bb016be@bytedance.com/

> 
> Thanks!
> 
>>
>> (I realize you're only enabling this for x86 for now, but we should
>> probably make sure the code is not arch-dependent in subtle
>> undocumented ways...)
>>
>>> +       free_pte(mm, addr, tlb, pmdval);
>>> +
>>> +       return;
>>> +out_ptl:
>>> +       pte_unmap_unlock(start_pte, ptl);
>>> +       if (pml != ptl)
>>> +               spin_unlock(pml);
>>> +}
>>> -- 
>>> 2.20.1
>>>