linux-kernel - Re: [PATCH] mm/thp: Update mm_struct's MM

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]

Date:   Fri, 21 May 2021 09:48:11 +0530
From:   Anshuman Khandual <anshuman.khandual@....com>
To:     Hugh Dickins <hughd@...gle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, Zi Yan <ziy@...dia.com>,
        Yang Shi <shy828301@...il.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm/thp: Update mm_struct's MM_ANONPAGES stat for huge
 zero pages

On 5/21/21 7:47 AM, Hugh Dickins wrote:
> On Tue, 18 May 2021, Anshuman Khandual wrote:
> 
>> Although the zero huge page is being shared across various processes, each
>> mapping needs to update its mm_struct's MM_ANONPAGES stat by HPAGE_PMD_NR
>> to be consistent. This just updates the stats in set_huge_zero_page() after
>> the mapping gets created and in zap_huge_pmd() when mapping gets destroyed.
>>
>> Cc: Andrew Morton <akpm@...ux-foundation.org>
>> Cc: Zi Yan <ziy@...dia.com>
>> Cc: linux-mm@...ck.org
>> Cc: linux-kernel@...r.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@....com>
> 
> NAK.
> 
> For consistency with what? In the all the years that the huge zero page

Huge zero page after all is an anon mapping. Hence why it must not be
counted for process rss MM_ANONPAGES accounting ? Is there a specific
reason why zero huge pages should not counted for MM_ANONPAGES ? Does
not it risk an inaccurate MM_ANONPAGES accounting for the processes
using huge zero pages ?

> has existed, it has been intentionally exempted from rss accounting:
> consistent with the small zero page, which itself has always been
> intentionally exempted from rss accounting. In fact, that's a good part

Why are small zero pages exempted from rss accounting which in turn
might have caused huge zero page to take the same approach as well ?

> of the reason the huge zero page was introduced (see 4a6c1297268c).

Huge zero page reduces memory consumption on read faults which is a
definite advantage but would there be a problem if rss stat goes up
for each huge zero page mapping instances. The commit mentioned here
talks about increase in actual memory utilization as seen from the
rss accounting stat, without huge zero page usage.

I am wondering if actual memory usage remains the same (reduced with
huge zero page usage), what could be the problem in an increased
MM_ANONPAGES accounting for a given process. Dont we update the rss
accounting for shared memory as well ?

> 
> To change that now will break any users depending on it.

Just to understand it correctly, are rss accounting procedures/methods
something which cannot be changed as users are currently dependent on
it ? OR this proposal here is not a good enough reason to change it ?

> 
> Not to mention the
> BUG: Bad rss-counter state mm:00000000aa61ef82 type:MM_ANONPAGES val:512
> I just got from mmotm.

Okay, unfortunately some how did not see this problem while testing. Is
there a specific test case which will be able to trigger this bug ?

- Anshuman