lkml.org 
[lkml]   [2017]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] mm: deferred_init_memmap improvements
From
Date
Hi Anshuman,

Thank you very much for looking at this. My reply below::

On 10/06/2017 02:48 AM, Anshuman Khandual wrote:
> On 10/04/2017 08:59 PM, Pavel Tatashin wrote:
>> This patch fixes another existing issue on systems that have holes in
>> zones i.e CONFIG_HOLES_IN_ZONE is defined.
>>
>> In for_each_mem_pfn_range() we have code like this:
>>
>> if (!pfn_valid_within(pfn)
>> goto free_range;
>>
>> Note: 'page' is not set to NULL and is not incremented but 'pfn' advances.
>
> page is initialized to NULL at the beginning of the function.

Yes, it is initialized to NULL but at the beginning of
for_each_mem_pfn_range() loop

> PFN advances but we dont proceed unless pfn_valid_within(pfn)
> holds true which basically should have checked with arch call
> back if the PFN is valid in presence of memory holes as well.
> Is not this correct ?

Correct, if pfn_valid_within() is false we jump to the "goto
free_range;", which is at the end of for (; pfn < end_pfn; pfn++) loop,
so we are not jumping outside of this loop.

>
>> Thus means if deferred struct pages are enabled on systems with these kind
>> of holes, linux would get memory corruptions. I have fixed this issue by
>> defining a new macro that performs all the necessary operations when we
>> free the current set of pages.
>
> If we bail out in case PFN is not valid, then how corruption
> can happen ?
>

We are not bailing out. We continue next iteration with next pfn, but
page is not incremented.

Please let me know if I am missing something.

Thank you,
Pasha

\
 
 \ /
  Last update: 2017-10-06 15:57    [W:0.043 / U:0.772 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site