Re: [v2 PATCH] mm: thp: check total_mapcount instead of page_mapcount

From: Zi Yan <ziy@nvidia.com>
To: Yang Shi <shy828301@gmail.com>
Cc: kirill.shutemov@linux.intel.com, wangyugui@e16-tech.com,
	hughd@google.com, akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [v2 PATCH] mm: thp: check total_mapcount instead of page_mapcount
Date: Fri, 14 May 2021 09:50:20 -0400	[thread overview]
Message-ID: <1E27805A-EC1E-4FCF-8C68-DA66FAE14E07@nvidia.com> (raw)
In-Reply-To: <20210513212334.217424-1-shy828301@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

On 13 May 2021, at 17:23, Yang Shi wrote:

> When debugging the bug reported by Wang Yugui [1], try_to_unmap() may
> return false positive for PTE-mapped THP since page_mapcount() is used
> to check if the THP is unmapped, but it just checks compound mapount and
> head page's mapcount.  If the THP is PTE-mapped and head page is not
> mapped, it may return false positive.
>
> Use total_mapcount() instead of page_mapcount() for try_to_unmap() and
> do so for the VM_BUG_ON_PAGE in split_huge_page_to_list as well.
>
> This changed the semantic of try_to_unmap(), but I don't see there is
> any usecase that expects try_to_unmap() just unmap one subpage of a huge
> page.  So using page_mapcount() seems like a bug.
>
> [1] https://lore.kernel.org/linux-mm/20210412180659.B9E3.409509F4@e16-tech.com/
>
> Signed-off-by: Yang Shi <shy828301@gmail.com>
> ---
> v2: Removed dead code and updated the comment of try_to_unmap() per Zi
>     Yan.
>
>  mm/huge_memory.c | 11 +----------
>  mm/rmap.c        | 10 ++++++----
>  2 files changed, 7 insertions(+), 14 deletions(-)

LGTM. Thanks. Reviewed-by: Zi Yan <ziy@nvidia.com>

—
Best Regards,
Yan Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]