[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3f485480-9474-4401-bc4f-fb66aac1e591@huawei.com>
Date: Fri, 10 Jun 2022 15:23:23 +0800
From: Miaohe Lin <linmiaohe@...wei.com>
To: Yang Shi <shy828301@...il.com>
CC: <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
<vbabka@...e.cz>, <kirill.shutemov@...ux.intel.com>,
<willy@...radead.org>, <akpm@...ux-foundation.org>
Subject: Re: [v3 PATCH 3/7] mm: khugepaged: remove the redundant anon vma
check
On 2022/6/7 5:44, Yang Shi wrote:
> The hugepage_vma_check() already checked it, so remove the redundant
> check.
>
> Signed-off-by: Yang Shi <shy828301@...il.com>
> ---
> mm/khugepaged.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index d0f8020164fc..7a5d1c1a1833 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -966,9 +966,6 @@ static int hugepage_vma_revalidate(struct mm_struct *mm, unsigned long address,
> return SCAN_ADDRESS_RANGE;
> if (!hugepage_vma_check(vma, vma->vm_flags))
> return SCAN_VMA_CHECK;
> - /* Anon VMA expected */
> - if (!vma->anon_vma || !vma_is_anonymous(vma))
> - return SCAN_VMA_CHECK;
Is it possible that hugepage_vma_check returns true due to the shmem check, or file thp check since
we dropped mmap_lock ? So anon vma is explicitly checked again here?
Thanks!
> return 0;
> }
>
>
Powered by blists - more mailing lists