Re: [PATCH] mm/hugetlb: avoid corrupting page->mapping in hugetlb_mcopy_atomic_pte

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2022/7/14 23:45, Peter Xu wrote:
> On Thu, Jul 14, 2022 at 06:09:49PM +0800, Miaohe Lin wrote:
>> As discussed in another thread, we might call page_dup_file_rmap for newly
>> allocated page (regardless of this patch). So should we come up a seperate
>> patch to call page_add_file_rmap here instead?
> 
> Hmm, why we need page_add_file_rmap() even if a new page allocated?  Say,
> we're at least also using page_dup_file_rmap() in hugetlb_no_page().
> 
> I see majorly two things extra there: memcg accounts on NR_FILE_MAPPED, and
> mlock.  But I assume both of them will not apply to hugetlb pages?

I think you are right. PageDoubleMap is also irrelevant for hugetlb.
page_add_file_rmap shouldn't be called for hugetlb page. It seems
page_dup_file_rmap can be regarded as hugetlb variant of page_add_file_rmap.
Sorry for making noise.

> 

Thanks.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux