[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9bea0112-0e4f-fde7-411a-243b53c34b91@huawei.com>
Date: Mon, 11 Jul 2022 15:14:07 +0800
From: Miaohe Lin <linmiaohe@...wei.com>
To: HORIGUCHI NAOYA(堀口 直也)
<naoya.horiguchi@....com>
CC: Naoya Horiguchi <naoya.horiguchi@...ux.dev>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Andrew Morton <akpm@...ux-foundation.org>,
David Hildenbrand <david@...hat.com>,
Mike Kravetz <mike.kravetz@...cle.com>,
Liu Shixin <liushixin2@...wei.com>,
Yang Shi <shy828301@...il.com>,
Oscar Salvador <osalvador@...e.de>,
Muchun Song <songmuchun@...edance.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [mm-unstable PATCH v5 3/8] mm, hwpoison, hugetlb: support saving
mechanism of raw error pages
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
>
Powered by blists - more mailing lists