linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Tatashin <pasha.tatashin@oracle.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: steven.sistare@oracle.com, daniel.m.jordan@oracle.com,
	akpm@linux-foundation.org, mgorman@techsingularity.net,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/1] mm: buddy page accessed before initialized
Date: Thu, 2 Nov 2017 09:39:58 -0400	[thread overview]
Message-ID: <a9b637b0-2ff0-80e8-76a7-801c5c0820a8@oracle.com> (raw)
In-Reply-To: <20171102133235.2vfmmut6w4of2y3j@dhcp22.suse.cz>

On 11/02/2017 09:32 AM, Michal Hocko wrote:
> On Tue 31-10-17 11:50:02, Pavel Tatashin wrote:
> [...]
>> The problem happens in this path:
>>
>> page_alloc_init_late
>>    deferred_init_memmap
>>      deferred_init_range
>>        __def_free
>>          deferred_free_range
>>            __free_pages_boot_core(page, order)
>>              __free_pages()
>>                __free_pages_ok()
>>                  free_one_page()
>>                    __free_one_page(page, pfn, zone, order, migratetype);
>>
>> deferred_init_range() initializes one page at a time by calling
>> __init_single_page(), once it initializes pageblock_nr_pages pages, it
>> calls deferred_free_range() to free the initialized pages to the buddy
>> allocator. Eventually, we reach __free_one_page(), where we compute buddy
>> page:
>> 	buddy_pfn = __find_buddy_pfn(pfn, order);
>> 	buddy = page + (buddy_pfn - pfn);
>>
>> buddy_pfn is computed as pfn ^ (1 << order), or pfn + pageblock_nr_pages.
>> Thefore, buddy page becomes a page one after the range that currently was
>> initialized, and we access this page in this function. Also, later when we
>> return back to deferred_init_range(), the buddy page is initialized again.
>>
>> So, in order to avoid this issue, we must initialize the buddy page prior
>> to calling deferred_free_range().
> 
> How come we didn't have this problem previously? I am really confused.
> 

Hi Michal,

Previously as before my project? That is because memory for all struct 
pages was always zeroed in memblock, and in __free_one_page() 
page_is_buddy() was always returning false, thus we never tried to 
incorrectly remove it from the list:

837			list_del(&buddy->lru);

Now, that memory is not zeroed, page_is_buddy() can return true after 
kexec when memory is dirty (unfortunately memset(1) with CONFIG_VM_DEBUG 
does not catch this case). And proceed further to incorrectly remove 
buddy from the list.

This is why we must initialize the computed buddy page beforehand.

Pasha

  reply	other threads:[~2017-11-02 13:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-31 15:50 [PATCH v1 0/1] buddy page accessed before initialized Pavel Tatashin
2017-10-31 15:50 ` [PATCH v1 1/1] mm: " Pavel Tatashin
2017-11-02 13:32   ` Michal Hocko
2017-11-02 13:39     ` Pavel Tatashin [this message]
2017-11-02 13:54       ` Michal Hocko
2017-11-02 14:00         ` Pavel Tatashin
2017-11-02 14:08           ` Michal Hocko
2017-11-02 14:16             ` Pavel Tatashin
2017-11-02 14:27               ` Michal Hocko
2017-11-02 16:10                 ` Pavel Tatashin
2017-11-03  8:59                   ` Michal Hocko
2017-11-03 14:17                     ` Pavel Tatashin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a9b637b0-2ff0-80e8-76a7-801c5c0820a8@oracle.com \
    --to=pasha.tatashin@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=daniel.m.jordan@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=steven.sistare@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).