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] [day] [month] [year] [list]

Date:   Fri, 21 Jan 2022 09:43:54 -0800
From:   Nadav Amit <nadav.amit@...il.com>
To:     David Hildenbrand <david@...hat.com>
Cc:     Matthew Wilcox <willy@...radead.org>,
        "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 Jan 21, 2022, at 1:01 AM, David Hildenbrand <david@...hat.com> wrote:
> 
>>> 
>>> I did hack something similar and it solved the problem, but I felt it is
>>> a hack. If the thread is scheduled on another core, or if the write fault
>>> is triggered by another thread it wouldn’t work.
>> 
>> Yes, it will not match easily. One question would be how often it would
>> help in practice and if it would be worth the price.
>> 
> 
> 
> I did some more testing and I have to admit that your reproducer is
> really good at finding corner cases.
> 
> Assume we try to handle LRU as discussed ... what I get is a delta
> during the test: ./forceswap 2 100000 1
> 
> 
> anon_wp_reuse 920
> -> we were able to reuse
> anon_wp_copy_count 0
> -> we failed the final page_count() == 1 check
> anon_wp_copy_count_early 634
> -> we failed the early page_count() check considering swapcache and lru
> anon_wp_copy_lock 1
> -> we failed trylock
> anon_wp_copy_lru 19
> -> we failed to clear the lru cache reference
> anon_wp_copy_writeback 99974
> -> we failed to clear the swapcache reference due to concurrent
>   writeback
> anon_wp_copy_swapcache 0
> -> we failed to clear the swapcache reference for other reasons
> 
> So, yeah, we mostly always hit writeback in forceswap.c.
> reuse_swap_page() would have been able to reuse the page if the swap
> backend would have supported concurrent writes during writeback (IIUC,
> zswap doesn't).
> 
> But I think triggering that case that often really is an oddity about
> the test case.

I am glad you find it useful (not my greatest piece of work).

IIRC, I encountered the scenario you describe. It happens when you use
a device driver that uses async operations (most of them). If you use
pmem, it does not happen.

This behavior is not intentional, anyhow.