All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@gmail.com>
To: Zaslonko Mikhail <zaslonko@linux.bm.com>
Cc: Wei Yang <richard.weiyang@gmail.com>,
	Michal Hocko <mhocko@kernel.org>,
	Mikhail Zaslonko <zaslonko@linux.ibm.com>,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, Pavel.Tatashin@microsoft.com,
	schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
	gerald.schaefer@de.ibm.com
Subject: Re: [PATCH 1/1] mm, memory_hotplug: Initialize struct pages for the full memory section
Date: Tue, 11 Dec 2018 22:24:15 +0000	[thread overview]
Message-ID: <20181211222415.yfco6l2dmywxgid7@master> (raw)
In-Reply-To: <e23ad186-31d4-176d-7330-8c22378891ee@linux.bm.com>

On Tue, Dec 11, 2018 at 04:17:34PM +0100, Zaslonko Mikhail wrote:
>
>
>On 11.12.2018 10:49, Wei Yang wrote:
>> On Mon, Dec 10, 2018 at 02:24:51PM +0100, Michal Hocko wrote:
>>> On Mon 10-12-18 14:07:12, Mikhail Zaslonko wrote:
>>>> If memory end is not aligned with the sparse memory section boundary, the
>>>> mapping of such a section is only partly initialized.
>>>
>>> It would be great to mention how you can end up in the situation like
>>> this(a user provided memmap or a strange HW). 
>>>
>>>> This may lead to
>>>> VM_BUG_ON due to uninitialized struct page access from
>>>> is_mem_section_removable() or test_pages_in_a_zone() function triggered by
>>>> memory_hotplug sysfs handlers:
>>>>
>>>>  page:000003d082008000 is uninitialized and poisoned
>>>>  page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
>>>>  Call Trace:
>>>>  ([<0000000000385b26>] test_pages_in_a_zone+0xde/0x160)
>>>>   [<00000000008f15c4>] show_valid_zones+0x5c/0x190
>>>>   [<00000000008cf9c4>] dev_attr_show+0x34/0x70
>>>>   [<0000000000463ad0>] sysfs_kf_seq_show+0xc8/0x148
>>>>   [<00000000003e4194>] seq_read+0x204/0x480
>>>>   [<00000000003b53ea>] __vfs_read+0x32/0x178
>>>>   [<00000000003b55b2>] vfs_read+0x82/0x138
>>>>   [<00000000003b5be2>] ksys_read+0x5a/0xb0
>>>>   [<0000000000b86ba0>] system_call+0xdc/0x2d8
>>>>  Last Breaking-Event-Address:
>>>>   [<0000000000385b26>] test_pages_in_a_zone+0xde/0x160
>>>>  Kernel panic - not syncing: Fatal exception: panic_on_oops
>>>>
>>>> Fix the problem by initializing the last memory section of the highest zone
>>>> in memmap_init_zone() till the very end, even if it goes beyond the zone
>>>> end.
>>>
>>> Why do we need to restrict this to the highest zone? In other words, why
>>> cannot we do what I was suggesting earlier [1]. What does prevent other
>>> zones to have an incomplete section boundary?
>>>
>>> [1] http://lkml.kernel.org/r/20181105183533.GQ4361@dhcp22.suse.cz
>>>
>> 
>> I tried to go through the original list and make myself familiar with
>> the bug.
>> 
>> Confused why initialize the *last* end_pfn could fix this, since
>> is_mem_section_removable() will iterate on each page of a section. This
>> means we need to initialize all the pages left in the section.
>That's exactly what the fix does. We initialize all the pages left in 
>the section.
>

You are right, I misunderstand your code.

>> 
>> One way to fix this in my mind is to record the last pfn in mem_section.
>Do you mean last initialized pfn? I guess we have agreed upon that the 
>entire section should be initialized.  

Well, that would be great.

>
>> This could be done in memory_preset(), since after that we may assume
>> the section is full. Not sure whether you would like it.
>> 

-- 
Wei Yang
Help you, Help me

  reply	other threads:[~2018-12-11 22:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-10 13:07 [PATCH 0/1] Initialize struct pages for the full section Mikhail Zaslonko
2018-12-10 13:07 ` [PATCH 1/1] mm, memory_hotplug: Initialize struct pages for the full memory section Mikhail Zaslonko
2018-12-10 13:24   ` Michal Hocko
2018-12-10 15:45     ` Zaslonko Mikhail
2018-12-10 18:19       ` Michal Hocko
2018-12-10 18:19         ` Michal Hocko
2018-12-11 15:18         ` Zaslonko Mikhail
2018-12-11  9:49     ` Wei Yang
2018-12-11 15:17       ` Zaslonko Mikhail
2018-12-11 22:24         ` Wei Yang [this message]
2018-12-10 15:10   ` Wei Yang
2018-12-10 16:14     ` Zaslonko Mikhail
2018-12-11  1:50       ` Wei Yang
2018-12-11 15:23         ` Zaslonko Mikhail
2018-12-11 22:14           ` Wei Yang
2018-12-10 21:09   ` Sasha Levin
2019-06-14 21:56   ` Sasha Levin

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=20181211222415.yfco6l2dmywxgid7@master \
    --to=richard.weiyang@gmail.com \
    --cc=Pavel.Tatashin@microsoft.com \
    --cc=akpm@linux-foundation.org \
    --cc=gerald.schaefer@de.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=zaslonko@linux.bm.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.