linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Zaslonko Mikhail <zaslonko@linux.vnet.ibm.com>
To: Pasha Tatashin <Pavel.Tatashin@microsoft.com>,
	Michal Hocko <mhocko@kernel.org>,
	Mikhail Zaslonko <zaslonko@linux.ibm.com>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"osalvador@suse.de" <osalvador@suse.de>,
	"gerald.schaefer@de.ibm.com" <gerald.schaefer@de.ibm.com>
Subject: Re: [PATCH] memory_hotplug: fix the panic when memory end is not on the section boundary
Date: Tue, 11 Sep 2018 16:08:09 +0200	[thread overview]
Message-ID: <639fd656-033b-0fdb-a182-83d4acf7fe2b@linux.vnet.ibm.com> (raw)
In-Reply-To: <e8d75768-9122-332b-3b16-cad032aeb27f@microsoft.com>



On 10.09.2018 15:46, Pasha Tatashin wrote:
>
> On 9/10/18 9:17 AM, Michal Hocko wrote:
>> [Cc Pavel]
>>
>> On Mon 10-09-18 14:35:27, Mikhail Zaslonko wrote:
>>> If memory end is not aligned with the linux memory section boundary, such
>>> a section is only partly initialized. This may lead to VM_BUG_ON due to
>>> uninitialized struct pages access from is_mem_section_removable() or
>>> test_pages_in_a_zone() function.
>>>
>>> Here is one of the panic examples:
>>>   CONFIG_DEBUG_VM_PGFLAGS=y
>>>   kernel parameter mem=3075M
>> OK, so the last memory section is not full and we have a partial memory
>> block right?
>>
>>>   page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
>> OK, this means that the struct page is not fully initialized. Do you
>> have a specific place which has triggered this assert?
>>
>>>   ------------[ cut here ]------------
>>>   Call Trace:
>>>   ([<000000000039b8a4>] is_mem_section_removable+0xcc/0x1c0)
>>>    [<00000000009558ba>] show_mem_removable+0xda/0xe0
>>>    [<00000000009325fc>] dev_attr_show+0x3c/0x80
>>>    [<000000000047e7ea>] sysfs_kf_seq_show+0xda/0x160
>>>    [<00000000003fc4e0>] seq_read+0x208/0x4c8
>>>    [<00000000003cb80e>] __vfs_read+0x46/0x180
>>>    [<00000000003cb9ce>] vfs_read+0x86/0x148
>>>    [<00000000003cc06a>] ksys_read+0x62/0xc0
>>>    [<0000000000c001c0>] system_call+0xdc/0x2d8
>>>
>>> This fix checks if the page lies within the zone boundaries before
>>> accessing the struct page data. The check is added to both functions.
>>> Actually similar check has already been present in
>>> is_pageblock_removable_nolock() function but only after the struct page
>>> is accessed.
>>>
>> Well, I am afraid this is not the proper solution. We are relying on the
>> full pageblock worth of initialized struct pages at many other place. We
>> used to do that in the past because we have initialized the full
>> section but this has been changed recently. Pavel, do you have any ideas
>> how to deal with this partial mem sections now?
> We have:
>
> remove_memory()
> 	BUG_ON(check_hotplug_memory_range(start, size))
>
> That supposed to safely check for this condition: if [start, start +
> size) not block size aligned (and we know block size is section
> aligned), hot remove is not allowed. The problem is this check is late,
> and only happens when invalid range has already passed through previous
> checks.
>
> We could add check_hotplug_memory_range() to is_mem_section_removable():
>
> is_mem_section_removable(start_pfn, nr_pages)
>   if (check_hotplug_memory_range(PFN_PHYS(start_pfn), PFN_PHYS(nr_pages)))
>    return false;
>
> I think it should work.

I don't think so since is_mem_section_removable() is called for for the 
entire
section. Thus [start_pfn, start_pfn + nr_pages) is always memory block 
aligned.

>
> Pavel
>
>>> Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
>>> Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
>>> Cc: <stable@vger.kernel.org>
>>> ---
>>>   mm/memory_hotplug.c | 20 +++++++++++---------
>>>   1 file changed, 11 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>>> index 9eea6e809a4e..8e20e8fcc3b0 100644
>>> --- a/mm/memory_hotplug.c
>>> +++ b/mm/memory_hotplug.c
>>> @@ -1229,9 +1229,8 @@ static struct page *next_active_pageblock(struct page *page)
>>>   	return page + pageblock_nr_pages;
>>>   }
>>>   
>>> -static bool is_pageblock_removable_nolock(struct page *page)
>>> +static bool is_pageblock_removable_nolock(struct page *page, struct zone **zone)
>>>   {
>>> -	struct zone *zone;
>>>   	unsigned long pfn;
>>>   
>>>   	/*
>>> @@ -1241,15 +1240,14 @@ static bool is_pageblock_removable_nolock(struct page *page)
>>>   	 * We have to take care about the node as well. If the node is offline
>>>   	 * its NODE_DATA will be NULL - see page_zone.
>>>   	 */
>>> -	if (!node_online(page_to_nid(page)))
>>> -		return false;
>>> -
>>> -	zone = page_zone(page);
>>>   	pfn = page_to_pfn(page);
>>> -	if (!zone_spans_pfn(zone, pfn))
>>> +	if (*zone && !zone_spans_pfn(*zone, pfn))
>>>   		return false;
>>> +	if (!node_online(page_to_nid(page)))
>>> +		return false;
>>> +	*zone = page_zone(page);
>>>   
>>> -	return !has_unmovable_pages(zone, page, 0, MIGRATE_MOVABLE, true);
>>> +	return !has_unmovable_pages(*zone, page, 0, MIGRATE_MOVABLE, true);
>>>   }
>>>   
>>>   /* Checks if this range of memory is likely to be hot-removable. */
>>> @@ -1257,10 +1255,11 @@ bool is_mem_section_removable(unsigned long start_pfn, unsigned long nr_pages)
>>>   {
>>>   	struct page *page = pfn_to_page(start_pfn);
>>>   	struct page *end_page = page + nr_pages;
>>> +	struct zone *zone = NULL;
>>>   
>>>   	/* Check the starting page of each pageblock within the range */
>>>   	for (; page < end_page; page = next_active_pageblock(page)) {
>>> -		if (!is_pageblock_removable_nolock(page))
>>> +		if (!is_pageblock_removable_nolock(page, &zone))
>>>   			return false;
>>>   		cond_resched();
>>>   	}
>>> @@ -1296,6 +1295,9 @@ int test_pages_in_a_zone(unsigned long start_pfn, unsigned long end_pfn,
>>>   				i++;
>>>   			if (i == MAX_ORDER_NR_PAGES || pfn + i >= end_pfn)
>>>   				continue;
>>> +			/* Check if we got outside of the zone */
>>> +			if (zone && !zone_spans_pfn(zone, pfn))
>>> +				return 0;
>>>   			page = pfn_to_page(pfn + i);
>>>   			if (zone && page_zone(page) != zone)
>>>   				return 0;
>>> -- 
>>> 2.16.4

  parent reply	other threads:[~2018-09-11 14:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-10 12:35 [PATCH] memory_hotplug: fix the panic when memory end is not on the section boundary Mikhail Zaslonko
2018-09-10 13:17 ` Michal Hocko
2018-09-10 13:46   ` Pasha Tatashin
2018-09-10 13:59     ` Michal Hocko
2018-09-10 14:11       ` Pasha Tatashin
2018-09-10 14:19         ` Michal Hocko
2018-09-10 14:32           ` Pasha Tatashin
2018-09-10 14:41             ` Michal Hocko
2018-09-10 15:26               ` Pasha Tatashin
2018-09-11  9:16                 ` Michal Hocko
2018-09-12 14:28                 ` Gerald Schaefer
2018-09-11 14:08     ` Zaslonko Mikhail [this message]
2018-09-11 14:06   ` Zaslonko Mikhail
2018-09-12 12:21     ` Michal Hocko
2018-09-12 13:03   ` Gerald Schaefer
2018-09-12 13:39     ` Michal Hocko
2018-09-12 14:27       ` Gerald Schaefer
2018-09-12 14:40         ` Pasha Tatashin
2018-09-12 15:51           ` Gerald Schaefer
2018-10-24 19:28           ` Zaslonko Mikhail

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=639fd656-033b-0fdb-a182-83d4acf7fe2b@linux.vnet.ibm.com \
    --to=zaslonko@linux.vnet.ibm.com \
    --cc=Pavel.Tatashin@microsoft.com \
    --cc=akpm@linux-foundation.org \
    --cc=gerald.schaefer@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=osalvador@suse.de \
    --cc=zaslonko@linux.ibm.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).