Re: [mm-unstable PATCH v5 3/8] mm, hwpoison, hugetlb: support saving mechanism of raw error pages

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

 



On 2022/7/11 13:51, HORIGUCHI NAOYA(堀口 直也) wrote:
> On Mon, Jul 11, 2022 at 11:26:34AM +0800, Miaohe Lin wrote:
>> On 2022/7/8 13:36, Naoya Horiguchi wrote:

<snip>

>> This patch looks good to me with below several possible problems:
>>
>> Should "nr_huge_pages" and "nr_huge_pages_node" be adjusted too? If it's called from dissolve_free_huge_page
>> and hugetlb_vmemmap_restore fails, add_hugetlb_page will be called:
>>
>> add_hugetlb_page:
>> 	...
>> 	h->nr_huge_pages++;
>> 	h->nr_huge_pages_node[nid]++;
>> 	   ^^^^^^^^1. the "nr_huge_pages" and "nr_huge_pages_node" might be incorrect?
>> 	...
>> 	zeroed = put_page_testzero(page);
>> 		 ^^^^^^^^2. VM_BUG_ON_PAGE(page_ref_count(page) == 0, page); will be triggered?
>>
>> Or am I miss something?
> 
> No, this code breaks the specific case, so I'd like to simply drop this if.
> HPageRawHwpUnreliable hugepage should be very rare, and calling page_mapped()
> for such a leaked page should be less common, so the impact of the slowdown
> should be minimal.

It makes sense for me to drop this if block.

Thanks.

> 
> Thanks,
> Naoya Horiguchi
> 





[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