linux-kernel - Re: [RFC PATCH v2 3/3] mm: mlock: update mlock_pte

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: <40cbc39e-5179-c2f4-3cea-0a98395aaff1@intel.com>
Date:   Mon, 17 Jul 2023 07:59:50 +0800
From:   "Yin, Fengwei" <fengwei.yin@...el.com>
To:     Yu Zhao <yuzhao@...gle.com>
CC:     <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
        <akpm@...ux-foundation.org>, <willy@...radead.org>,
        <david@...hat.com>, <ryan.roberts@....com>, <shy828301@...il.com>
Subject: Re: [RFC PATCH v2 3/3] mm: mlock: update mlock_pte_range to handle
 large folio



On 7/15/2023 2:06 PM, Yu Zhao wrote:
> There is a problem here that I didn't have the time to elaborate: we
> can't mlock() a folio that is within the range but not fully mapped
> because this folio can be on the deferred split queue. When the split
> happens, those unmapped folios (not mapped by this vma but are mapped
> into other vmas) will be stranded on the unevictable lru.
This should be fine unless I missed something. During large folio split,
the unmap_folio() will be migrate(anon)/unmap(file) folio. Folio will be
munlocked in unmap_folio(). So the head/tail pages will be evictable always.

> 
> For that matter, we can't mlock any large folios that are being
> shared, unless you want to overengineer it by checking whether all
> sharing vmas are also mlocked -- mlock is cleared during fork. So the
> condition for mlocking large anon folios is 1) within range 2) fully
> mapped 3) not shared (mapcount is 1). The final patch should look like
> something like this:
> 
> -  if (folio_test_large(folio))
> +  if (folio_pfn(folio) != pte_pfn(ptent))
> +    continue;
> +  if (!the_aforementioned_condition())
> 
> There is another corner case I forgot to mention: for example, what if
> a folio spans two (the only two) adjacent mlocked vmas? No need to
> worry about this since it's not worth optimizing.
Yes. The behavior will be related with whether the folio is mlocked or not.
But the worst case is the folio is split and each page is mlocked during
next scan again.


Regards
Yin, Fengwei