On Mon, May 6, 2019 at 10:40 PM Sasha Levin <[email protected]> wrote: > > From: Mikhail Zaslonko <[email protected]> > > [ 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/[email protected] > Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap") > Signed-off-by: Mikhail Zaslonko <[email protected]> > Reviewed-by: Gerald Schaefer <[email protected]> > Suggested-by: Michal Hocko <[email protected]> > Acked-by: Michal Hocko <[email protected]> > Reported-by: Mikhail Gavrilov <[email protected]> > Tested-by: Mikhail Gavrilov <[email protected]> > Cc: Dave Hansen <[email protected]> > Cc: Alexander Duyck <[email protected]> > Cc: Pasha Tatashin <[email protected]> > Cc: Martin Schwidefsky <[email protected]> > Cc: Heiko Carstens <[email protected]> > Cc: <[email protected]> > Signed-off-by: Andrew Morton <[email protected]> > Signed-off-by: Linus Torvalds <[email protected]> > Signed-off-by: Sasha Levin <[email protected]> > --- > 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?
