On Wed, Nov 20, 2019 at 04:07:38PM +0100, David Hildenbrand wrote:
>On 18.11.19 09:20, Wei Yang wrote:
>> hpage is not changed.
>>
>> Signed-off-by: Wei Yang <richardw.yang@xxxxxxxxxxxxxxx>
>> ---
>> mm/memory-failure.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
>> index 392ac277b17d..9784f4339ae7 100644
>> --- a/mm/memory-failure.c
>> +++ b/mm/memory-failure.c
>> @@ -1319,7 +1319,6 @@ int memory_failure(unsigned long pfn, int flags)
>> }
>> unlock_page(p);
>> VM_BUG_ON_PAGE(!page_count(p), p);
>> - hpage = compound_head(p);
>> }
>> /*
>>
>
>I am *absolutely* no transparent huge page expert (sorry :) ), but won't the
>split_huge_page(p) eventually split the compound page, such that
>compound_head(p) will return something else after that call?
>
Hi, David
Took sometime to look into the code and re-think about it. Found maybe we can
simplify this in another way.
First, code touches here means split_huge_page() succeeds and "p" is now a PTE
page. So compound_head(p) == p.
Then let's look at who will use hpage in the following function. There are two
uses in current upstream:
* page_flags calculation
* hwpoison_user_mappings()
The first one would be removed in next patch since PageHuge is handled at the
beginning.
And in the second place, comment says if split succeeds, hpage points to page
"p".
After all, we don't need to re-calculate hpage after split, and just replace
hpage in hwpoison_user_mappings() with p is enough.
>--
>
>Thanks,
>
>David / dhildenb
--
Wei Yang
Help you, Help me
