[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1E27805A-EC1E-4FCF-8C68-DA66FAE14E07@nvidia.com>
Date: Fri, 14 May 2021 09:50:20 -0400
From: Zi Yan <ziy@...dia.com>
To: Yang Shi <shy828301@...il.com>
Cc: kirill.shutemov@...ux.intel.com, wangyugui@...-tech.com,
hughd@...gle.com, akpm@...ux-foundation.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [v2 PATCH] mm: thp: check total_mapcount instead of page_mapcount
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@...il.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@...dia.com>
—
Best Regards,
Yan Zi
Download attachment "signature.asc" of type "application/pgp-signature" (855 bytes)
Powered by blists - more mailing lists