linux-kernel - Re: [PATCH v3 2/2] mm/page_alloc: add some comments to explain the possible hole in __pageblock_pfn_to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <98fa0a22-77d1-cdb3-1ce2-48a00c3ed5a9@linux.alibaba.com>
Date:   Tue, 25 Apr 2023 20:29:16 +0800
From:   Baolin Wang <baolin.wang@...ux.alibaba.com>
To:     Michal Hocko <mhocko@...e.com>
Cc:     "Huang, Ying" <ying.huang@...el.com>, akpm@...ux-foundation.org,
        rppt@...nel.org, mgorman@...hsingularity.net, vbabka@...e.cz,
        david@...hat.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] mm/page_alloc: add some comments to explain the
 possible hole in __pageblock_pfn_to_page()



On 4/25/2023 5:05 PM, Michal Hocko wrote:
> On Tue 25-04-23 09:27:23, Baolin Wang wrote:
>>
>>
>> On 4/25/2023 8:22 AM, Huang, Ying wrote:
>>> Baolin Wang <baolin.wang@...ux.alibaba.com> writes:
> [...]
>>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>>> index 6457b64fe562..bd124390c79b 100644
>>>> --- a/mm/page_alloc.c
>>>> +++ b/mm/page_alloc.c
>>>> @@ -1502,6 +1502,15 @@ void __free_pages_core(struct page *page, unsigned int order)
>>>>     * interleaving within a single pageblock. It is therefore sufficient to check
>>>>     * the first and last page of a pageblock and avoid checking each individual
>>>>     * page in a pageblock.
>>>> + *
>>>> + * Note: the function may return non-NULL struct page even for a page block
>>>> + * which contains a memory hole (i.e. there is no physical memory for a subset
>>>> + * of the pfn range). For example, if the pageblock order is MAX_ORDER, which
>>>> + * will fall into 2 sub-sections, and the end pfn of the pageblock may be hole
>>>> + * even though the start pfn is online and valid. This should be safe most of
>>>> + * the time because struct pages are still zero pre-filled and pfn walkers
>>>
>>> I don't think the pfn is just zero-filled even it's a hole.  Can you
>>> confirm that?  In memmap_init() and memmap_init_zone_range(),
>>> init_unavailable_range() is called to initialize the struct page.
>>
>> Yes, what I mean is the page frames were initialized to zero firstly, and
>> some fields were initialized to default value. The "zero pre-filled" seems
>> confusing, may be change to "initialized"?
> 
> Huang Ying is correct. Holes should have struct pages initialized and
> init_unavailable_range actually marks those pages reserved. Which
> is really good because they mean "do not touch unless this page is
> yours". For some reason I thought those struct pages are simply zero
> filled. I was clearly wrong. Maybe it would be good to reference
> init_unavailable_range in the comment so that it is easier to track the
> whole code path.

OK, will do as you and Huang Ying suggested. Thank you both.

> Sorry about that!

never mind:)