Messages in this thread | | | From | Alexander Duyck <> | Date | Tue, 7 May 2019 09:31:10 -0700 | Subject | Re: [PATCH AUTOSEL 4.14 62/95] mm, memory_hotplug: initialize struct pages for the full memory section |
| |
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?
| |