linux-kernel - Re: [PATCH] mm: reuse the unshared swapcache page in do_wp

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: <Yel0BXVyj8uvsWJX@casper.infradead.org>
Date:   Thu, 20 Jan 2022 14:39:01 +0000
From:   Matthew Wilcox <willy@...radead.org>
To:     David Hildenbrand <david@...hat.com>
Cc:     "zhangliang (AG)" <zhangliang5@...wei.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux-MM <linux-mm@...ck.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        wangzhigang17@...wei.com,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] mm: reuse the unshared swapcache page in do_wp_page

On Thu, Jan 20, 2022 at 03:15:37PM +0100, David Hildenbrand wrote:
> On 17.01.22 14:31, zhangliang (AG) wrote:
> > Sure, I will do that :)
> 
> I'm polishing up / testing the patches and might send something out for discussion shortly.
> Just a note that on my branch was a version with a wrong condition that should have been fixed now.
> 
> I am still thinking about PTE mapped THP. For these, we'll always
> have page_count() > 1, essentially corresponding to the number of still-mapped sub-pages.
> 
> So if we end up with a R/O mapped part of a THP, we'll always have to COW and cannot reuse ever,
> although it's really just a single process mapping the THP via PTEs.
> 
> One approach would be to scan the currently locked page table for entries mapping
> this same page. If page_count() corresponds to that value, we know that only we are
> mapping the THP and there are no additional references. That would be a special case
> if we find an anon THP in do_wp_page(). Hm.

You're starting to optimise for some pretty weird cases at that point.
Anon THP is always going to start out aligned (and can be moved by
mremap()).  Arguably it should be broken up if it's moved so it can be
reformed into aligned THPs by khugepaged.

This is completely different from file-backed THPs, where misalignment
might be considered normal (if unfortunate).