Messages in this thread | | | Date | Tue, 7 May 2019 12:58:00 -0400 | From | Sasha Levin <> | Subject | Re: [PATCH AUTOSEL 4.14 62/95] mm, memory_hotplug: initialize struct pages for the full memory section |
| |
On Tue, May 07, 2019 at 09:31:10AM -0700, Alexander Duyck wrote: >On Mon, May 6, 2019 at 10:40 PM Sasha Levin <sashal@kernel.org> wrote: >> >> From: Mikhail Zaslonko <zaslonko@linux.ibm.com> >> >> [ Upstream commit 2830bf6f05fb3e05bc4743274b806c821807a684 ] >> >> If memory end is not aligned with the sparse memory section boundary, >> the mapping of such a section is only partly initialized. 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: >> >> Here are the the panic examples: >> CONFIG_DEBUG_VM=y >> CONFIG_DEBUG_VM_PGFLAGS=y >> >> kernel parameter mem=2050M >> -------------------------- >> page:000003d082008000 is uninitialized and poisoned >> page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p)) >> Call Trace: >> ( test_pages_in_a_zone+0xde/0x160) >> show_valid_zones+0x5c/0x190 >> dev_attr_show+0x34/0x70 >> sysfs_kf_seq_show+0xc8/0x148 >> seq_read+0x204/0x480 >> __vfs_read+0x32/0x178 >> vfs_read+0x82/0x138 >> ksys_read+0x5a/0xb0 >> system_call+0xdc/0x2d8 >> Last Breaking-Event-Address: >> test_pages_in_a_zone+0xde/0x160 >> Kernel panic - not syncing: Fatal exception: panic_on_oops >> >> kernel parameter mem=3075M >> -------------------------- >> page:000003d08300c000 is uninitialized and poisoned >> page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p)) >> Call Trace: >> ( is_mem_section_removable+0xb4/0x190) >> show_mem_removable+0x9a/0xd8 >> dev_attr_show+0x34/0x70 >> sysfs_kf_seq_show+0xc8/0x148 >> seq_read+0x204/0x480 >> __vfs_read+0x32/0x178 >> vfs_read+0x82/0x138 >> ksys_read+0x5a/0xb0 >> system_call+0xdc/0x2d8 >> Last Breaking-Event-Address: >> is_mem_section_removable+0xb4/0x190 >> Kernel panic - not syncing: Fatal exception: panic_on_oops >> >> Fix the problem by initializing the last memory section of each zone in >> memmap_init_zone() till the very end, even if it goes beyond the zone end. >> >> Michal said: >> >> : This has alwways been problem AFAIU. It just went unnoticed because we >> : have zeroed memmaps during allocation before f7f99100d8d9 ("mm: stop >> : zeroing memory during allocation in vmemmap") and so the above test >> : would simply skip these ranges as belonging to zone 0 or provided a >> : garbage. >> : >> : So I guess we do care for post f7f99100d8d9 kernels mostly and >> : therefore Fixes: f7f99100d8d9 ("mm: stop zeroing memory during >> : allocation in vmemmap") >> >> Link: http://lkml.kernel.org/r/20181212172712.34019-2-zaslonko@linux.ibm.com >> Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap") >> Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com> >> Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> >> Suggested-by: Michal Hocko <mhocko@kernel.org> >> Acked-by: Michal Hocko <mhocko@suse.com> >> Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> >> Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> >> Cc: Dave Hansen <dave.hansen@intel.com> >> Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com> >> Cc: Pasha Tatashin <Pavel.Tatashin@microsoft.com> >> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> >> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> >> Cc: <stable@vger.kernel.org> >> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> >> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> >> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> >> --- >> mm/page_alloc.c | 12 ++++++++++++ >> 1 file changed, 12 insertions(+) > >Wasn't this patch reverted in Linus's tree for causing a regression on >some platforms? If so I'm not sure we should pull this in as a >candidate for stable should we, or am I missing something?
I saw a follow-up patch that should be queued too, but I didn't see that this one got reverted.
-- Thanks, Sasha
| |