Commit f10628d2 authored by Michal Hocko's avatar Michal Hocko Committed by Linus Torvalds

Revert "mm/gup: check page posion status for coredump."

While reviewing [1] I came across commit d3378e86 ("mm/gup: check
page posion status for coredump.") and noticed that this patch is broken
in two ways.  First it doesn't really prevent hwpoison pages from being
dumped because hwpoison pages can be marked asynchornously at any time
after the check.  Secondly, and more importantly, the patch introduces a
ref count leak because get_dump_page takes a reference on the page which
is not released.

It also seems that the patch was merged incorrectly because there were
follow up changes not included as well as discussions on how to address
the underlying problem [2]

Therefore revert the original patch.

Link: http://lkml.kernel.org/r/20210429122519.15183-4-david@redhat.com [1]
Link: http://lkml.kernel.org/r/57ac524c-b49a-99ec-c1e4-ef5027bfb61b@redhat.com [2]
Link: https://lkml.kernel.org/r/20210505135407.31590-1-mhocko@kernel.org
Fixes: d3378e86 ("mm/gup: check page posion status for coredump.")
Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
Cc: Aili Yao <yaoaili@kingsoft.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
parent f9f74dc2
......@@ -1593,10 +1593,6 @@ struct page *get_dump_page(unsigned long addr)
FOLL_FORCE | FOLL_DUMP | FOLL_GET);
if (locked)
mmap_read_unlock(mm);
if (ret == 1 && is_page_poisoned(page))
return NULL;
return (ret == 1) ? page : NULL;
}
#endif /* CONFIG_ELF_CORE */
......
......@@ -96,26 +96,6 @@ static inline void set_page_refcounted(struct page *page)
set_page_count(page, 1);
}
/*
* When kernel touch the user page, the user page may be have been marked
* poison but still mapped in user space, if without this page, the kernel
* can guarantee the data integrity and operation success, the kernel is
* better to check the posion status and avoid touching it, be good not to
* panic, coredump for process fatal signal is a sample case matching this
* scenario. Or if kernel can't guarantee the data integrity, it's better
* not to call this function, let kernel touch the poison page and get to
* panic.
*/
static inline bool is_page_poisoned(struct page *page)
{
if (PageHWPoison(page))
return true;
else if (PageHuge(page) && PageHWPoison(compound_head(page)))
return true;
return false;
}
extern unsigned long highest_memmap_pfn;
/*
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment