linux-kernel - Re: [RFC PATCH] mm: hold PTL from the first PTE while reclaiming a large folio

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: <CAGsJ_4w1dhqCu6UA4LGt9XDU_2jmcmWm1=E9MzX2tRv85NrLuw@mail.gmail.com>
Date: Tue, 5 Mar 2024 22:11:37 +1300
From: Barry Song <21cnbao@...il.com>
To: Ryan Roberts <ryan.roberts@....com>
Cc: "Huang, Ying" <ying.huang@...el.com>, akpm@...ux-foundation.org, linux-mm@...ck.org, 
	david@...hat.com, chrisl@...nel.org, yuzhao@...gle.com, hanchuanhua@...o.com, 
	linux-kernel@...r.kernel.org, willy@...radead.org, xiang@...nel.org, 
	mhocko@...e.com, shy828301@...il.com, wangkefeng.wang@...wei.com, 
	Barry Song <v-songbaohua@...o.com>, Hugh Dickins <hughd@...gle.com>
Subject: Re: [RFC PATCH] mm: hold PTL from the first PTE while reclaiming a
 large folio

On Tue, Mar 5, 2024 at 10:08 PM Ryan Roberts <ryan.roberts@....com> wrote:
>
> On 05/03/2024 08:56, Barry Song wrote:
> > are writing pte to zero(break) before writing a new value(make). while
>
> As an aside, "break-before-make" as defined in the Arm architecture would also
> require a TLBI, which usually isn't done for these
> write-0-modify-prots-write-back operations. Arm doesn't require
> "break-before-make" in these situations so its legal (as long as only certain
> bits are changed). To my understanding purpose of doing this is to avoid races
> with HW access/dirty flag updates; if the MMU wants to set either flag and finds
> the PTE is 0 (invalid) it will cause an exception which will be queued waiting
> for the PTL.
>
> So I don't think you really mean break-before-make here.

I agree I use a stronger term. will change it to something lighter in v2.

>
> > this behavior is within PTL in another thread,  page_vma_mapped_walk()
> > of try_to_unmap_one thread won't take PTL till it meets a present PTE.
> > for example, if another threads are modifying nr_pages PTEs under PTL,
> > but we don't hold PTL, we might skip one or two PTEs at the beginning of
> > a large folio.
> > For a large folio, after try_to_unmap_one(), we may result in PTE0 and PTE1
> > untouched but PTE2~nr_pages-1 are set to swap entries.
> >
> > by holding PTL from PTE0 for large folios, we won't get these intermediate
> > values. At the moment we get PTL, other threads have done.
>

Thanks
Barry