linux-kernel - Re: [PATCH 2/4] mm/rmap: fix old bug: munlocking THP missed other mlocks

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: <20210708135811.775drqgwkwc76vcb@box.shutemov.name>
Date:   Thu, 8 Jul 2021 16:58:11 +0300
From:   "Kirill A. Shutemov" <kirill@...temov.name>
To:     Hugh Dickins <hughd@...gle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Alistair Popple <apopple@...dia.com>,
        Jason Gunthorpe <jgg@...dia.com>,
        Ralph Campbell <rcampbell@...dia.com>,
        Christoph Hellwig <hch@....de>, Yang Shi <shy828301@...il.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Shakeel Butt <shakeelb@...gle.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 2/4] mm/rmap: fix old bug: munlocking THP missed other
 mlocks

On Wed, Jul 07, 2021 at 01:08:53PM -0700, Hugh Dickins wrote:
> The kernel recovers in due course from missing Mlocked pages: but there
> was no point in calling page_mlock() (formerly known as try_to_munlock())
> on a THP, because nothing got done even when it was found to be mapped in
> another VM_LOCKED vma.
> 
> It's true that we need to be careful: Mlocked accounting of pte-mapped
> THPs is too difficult (so consistently avoided); but Mlocked accounting
> of only-pmd-mapped THPs is supposed to work, even when multiple mappings
> are mlocked and munlocked or munmapped.  Refine the tests.

Well, that's true that it should be fine to mlock only-pmd-mapped THPs,
but the refined check doesn't gurantee that the page is not mapped with
PTEs. !PageDoubleMap(page) only guarantees that the page in not mapped
with both PMDs and PTEs at the same time. For anon pages, we clear the
flag when the last PMD mapping is gone and only PTEs left.

Do I miss some detail here? Maybe we exclude anon pages here somehow?
I don't see it.

-- 
 Kirill A. Shutemov