[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <519ec924-483c-aec0-cb84-b33b25ce92b4@huawei.com>
Date: Fri, 10 Jun 2022 15:28: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/10 15:23, Miaohe Lin wrote:
> 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?
I just see your discussion with similar problem. Sorry for make noise.
>
> Thanks!
>
>> return 0;
>> }
>>
>>
>
Powered by blists - more mailing lists