linux-kernel - Re: [PATCH] arm64: mm: support THP

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: <ZXMYe2IDVll6pBn9@casper.infradead.org>
Date:   Fri, 8 Dec 2023 13:22:03 +0000
From:   Matthew Wilcox <willy@...radead.org>
To:     Barry Song <21cnbao@...il.com>
Cc:     akpm@...ux-foundation.org, catalin.marinas@....com,
        david@...hat.com, linux-mm@...ck.org, ryan.roberts@....com,
        steven.price@....com, will@...nel.org,
        linux-arm-kernel@...ts.infradead.org, mhocko@...e.com,
        shy828301@...il.com, v-songbaohua@...o.com,
        wangkefeng.wang@...wei.com, xiang@...nel.org, ying.huang@...el.com,
        yuzhao@...gle.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: mm: support THP_SWAP on hardware with MTE

On Fri, Dec 08, 2023 at 08:34:01PM +1300, Barry Song wrote:
> arch_prepare_to_swap() should take folio rather than page as parameter
> because we support THP swap-out as a whole. It saves tags for all
> pages in a large folio.
> 
> Meanwhile, arch_swap_restore() now moves to use page parameter rather
> than folio because swap-in, refault and MTE tags are working at the
> granularity of base pages rather than folio:
> 1. a large folio in swapcache can be partially unmapped, thus, MTE
> tags for the unmapped pages will be invalidated;
> 2. users might use mprotect() to set MTEs on a part of a large folio.

I would argue that using mprotect() to set MTEs on part of a large folio
should cause that folio to be split.  Could the user give us any
stronger signal that this memory is being used for different purposes,
and therefore should not be managed as a single entity?

> Thus, it won't be easy to manage MTE tags at the granularity of folios
> since we do have some cases in which a part of pages in a large folios
> have valid tags, while the other part of pages haven't. Furthermore,
> trying to restore MTE tags for a whole folio can lead to many loops and
> early exiting even if the large folio in swapcache are still entirely
> mapped since do_swap_page() only sets PTE and frees swap for the base
> page where PF is happening.
> 
> But we still have a chance to restore tags for a whole large folio
> once we support swap-in large folio. So this job is deferred till we
> can do refault and swap-in as a large folio.

I strongly disagree with changing the interface to arch_swap_restore()
from folio to page.