linux-kernel - Re: [PATCH v6 0/6] ksm: support tracking KSM-placed zero-pages

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: <20230330120654.120937-1-xu.xin16@zte.com.cn>
Date:   Thu, 30 Mar 2023 12:06:54 +0000
From:   xu xin <xu.xin.sc@...il.com>
To:     david@...hat.com
Cc:     akpm@...ux-foundation.org, imbrenda@...ux.ibm.com,
        jiang.xuexin@....com.cn, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, ran.xiaokai@....com.cn, xu.xin.sc@...il.com,
        xu.xin16@....com.cn, yang.yang29@....com.cn
Subject: Re: [PATCH v6 0/6] ksm: support tracking KSM-placed zero-pages

Hi, I'm sorry to reply so late because I was so busy with my job matters recently.

I appreciate David's idea of simplifying the implement of tracking KSM-placed zero pages.
But I'm confused with how to implement that via pte_mkdirty/pte_dirty without affecting
other functions now and in the future.

>
>I already shared some feedback in [1]. I think we should try to simplify 
>this handling, as proposed in that mail. Still waiting for a reply.
>
>[1] 
>https://lore.kernel.org/all/9d7a8be3-ee9e-3492-841b-a0af9952ef36@redhat.com/

I have some questions about using pte_mkdirty to mark KSM-placed zero pages.

(1) Will KSM using pte_mkdirty to mark KSM-placed zero pages collides with the existing
    handling of the same pte in other featutes? And in the future, what if there are new
    codes also using pte_mkdirty for other goals.

(2) Can the literal meaning of pte_mkdiry represents a pte that points to ksm zero page?

(3) Suppose we use the pte_mkdirty approach, how to update/decline the count of ksm_zero_pages
    when upper app writting on the page triggers COW(Copy on Write)? In *mm_fault outside
    mm/ksm.c ?

Move the previos message here to reply together.
>The problem with this approach I see is that it fundamentally relies on 
>the rmap/stable-tree to detect whether a zeropage was placed or not.
>
>I was wondering, why we even need an rmap item *at all* anymore. Why 
>can't we place the shared zeropage an call it a day (remove the rmap 
>item)? Once we placed a shared zeropage, the next KSM scan should better 
>just ignore it, it's already deduplicated.

The reason is as follows ...
Initially, all scanned pages by ksmd will be assigned a rmap_item storing the page
information and ksm information, which helps ksmd can know every scanned pages' status and
update all counts especialy when COW happens. But since use_zero_pages feature was merged,
the situation changed, ksm zero pages is the only exception of ksm-scanned page without owning
a rmap_item in KSM, which leads to ksmd even don't know the existing of KSM-placed, and thus
causes the problem of our patches aimed to solve.