Rewrite copy_huge_page() and move it into mm/util.c so it's always
available. Fixes an exposure of uninitialised memory on configurations
with HUGETLB and UFFD enabled and MIGRATION disabled.
Fixes: 8cc5fcbb5be8 ("mm, hugetlb: fix racy resv_huge_pages underflow on UFFDIO_COPY")
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
---
include/linux/migrate.h | 5 -----
include/linux/mm.h | 1 +
mm/migrate.c | 48 -----------------------------------------
mm/util.c | 10 +++++++++
4 files changed, 11 insertions(+), 53 deletions(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index 9b7b7cd3bae9..23dadf7aeba8 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -51,7 +51,6 @@ extern int migrate_huge_page_move_mapping(struct address_space *mapping,
struct page *newpage, struct page *page);
extern int migrate_page_move_mapping(struct address_space *mapping,
struct page *newpage, struct page *page, int extra_count);
-extern void copy_huge_page(struct page *dst, struct page *src);
#else
static inline void putback_movable_pages(struct list_head *l) {}
@@ -77,10 +76,6 @@ static inline int migrate_huge_page_move_mapping(struct address_space *mapping,
{
return -ENOSYS;
}
-
-static inline void copy_huge_page(struct page *dst, struct page *src)
-{
-}
#endif /* CONFIG_MIGRATION */
#ifdef CONFIG_COMPACTION
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 8f8e9d8a8489..629df6a24527 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -874,6 +874,7 @@ void __put_page(struct page *page);
void put_pages_list(struct list_head *pages);
void split_page(struct page *page, unsigned int order);
+void copy_huge_page(struct page *dst, struct page *src);
/*
* Compound pages have a destructor function. Provide a
diff --git a/mm/migrate.c b/mm/migrate.c
index 23cbd9de030b..34a9ad3e0a4f 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -536,54 +536,6 @@ int migrate_huge_page_move_mapping(struct address_space *mapping,
return MIGRATEPAGE_SUCCESS;
}
-/*
- * Gigantic pages are so large that we do not guarantee that page++ pointer
- * arithmetic will work across the entire page. We need something more
- * specialized.
- */
-static void __copy_gigantic_page(struct page *dst, struct page *src,
- int nr_pages)
-{
- int i;
- struct page *dst_base = dst;
- struct page *src_base = src;
-
- for (i = 0; i < nr_pages; ) {
- cond_resched();
- copy_highpage(dst, src);
-
- i++;
- dst = mem_map_next(dst, dst_base, i);
- src = mem_map_next(src, src_base, i);
- }
-}
-
-void copy_huge_page(struct page *dst, struct page *src)
-{
- int i;
- int nr_pages;
-
- if (PageHuge(src)) {
- /* hugetlbfs page */
- struct hstate *h = page_hstate(src);
- nr_pages = pages_per_huge_page(h);
-
- if (unlikely(nr_pages > MAX_ORDER_NR_PAGES)) {
- __copy_gigantic_page(dst, src, nr_pages);
- return;
- }
- } else {
- /* thp page */
- BUG_ON(!PageTransHuge(src));
- nr_pages = thp_nr_pages(src);
- }
-
- for (i = 0; i < nr_pages; i++) {
- cond_resched();
- copy_highpage(dst + i, src + i);
- }
-}
-
/*
* Copy the page to its new location
*/
diff --git a/mm/util.c b/mm/util.c
index 99c6cc77de9e..9043d03750a7 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -731,6 +731,16 @@ int __page_mapcount(struct page *page)
}
EXPORT_SYMBOL_GPL(__page_mapcount);
+void copy_huge_page(struct page *dst, struct page *src)
+{
+ unsigned i, nr = compound_nr(src);
+
+ for (i = 0; i < nr; i++) {
+ cond_resched();
+ copy_highpage(nth_page(dst, i), nth_page(src, i));
+ }
+}
+
int sysctl_overcommit_memory __read_mostly = OVERCOMMIT_GUESS;
int sysctl_overcommit_ratio __read_mostly = 50;
unsigned long sysctl_overcommit_kbytes __read_mostly;
--
2.30.2
On 7/12/21 8:32 AM, Matthew Wilcox (Oracle) wrote:
> Rewrite copy_huge_page() and move it into mm/util.c so it's always
> available. Fixes an exposure of uninitialised memory on configurations
> with HUGETLB and UFFD enabled and MIGRATION disabled.
>
> Fixes: 8cc5fcbb5be8 ("mm, hugetlb: fix racy resv_huge_pages underflow on UFFDIO_COPY")
> Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
> ---
> include/linux/migrate.h | 5 -----
> include/linux/mm.h | 1 +
> mm/migrate.c | 48 -----------------------------------------
> mm/util.c | 10 +++++++++
> 4 files changed, 11 insertions(+), 53 deletions(-)
Thanks Matthew,
Reviewed-by: Mike Kravetz <[email protected]>
--
Mike Kravetz
On Mon, Jul 12, 2021 at 10:52 AM Mike Kravetz <[email protected]> wrote:
>
> On 7/12/21 8:32 AM, Matthew Wilcox (Oracle) wrote:
> > Rewrite copy_huge_page() and move it into mm/util.c so it's always
> > available. Fixes an exposure of uninitialised memory on configurations
> > with HUGETLB and UFFD enabled and MIGRATION disabled.
> >
> > Fixes: 8cc5fcbb5be8 ("mm, hugetlb: fix racy resv_huge_pages underflow on UFFDIO_COPY")
> > Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
Reviewed-By: Mina Almasry <[email protected]>
> > ---
> > include/linux/migrate.h | 5 -----
> > include/linux/mm.h | 1 +
> > mm/migrate.c | 48 -----------------------------------------
> > mm/util.c | 10 +++++++++
> > 4 files changed, 11 insertions(+), 53 deletions(-)
>
> Thanks Matthew,
>
> Reviewed-by: Mike Kravetz <[email protected]>
> --
> Mike Kravetz
On Mon, 12 Jul 2021 16:32:07 +0100 "Matthew Wilcox (Oracle)" <[email protected]> wrote:
> Rewrite copy_huge_page() and move it into mm/util.c so it's always
> available. Fixes an exposure of uninitialised memory on configurations
> with HUGETLB and UFFD enabled and MIGRATION disabled.
Wait. Exposing uninitialized memory is serious. Can we please include
full info on this flaw and decide whether a -stable backport is justified?
If not, why not, etc?
On Tue, Jul 13, 2021 at 07:12:44PM -0700, Andrew Morton wrote:
> On Mon, 12 Jul 2021 16:32:07 +0100 "Matthew Wilcox (Oracle)" <[email protected]> wrote:
>
> > Rewrite copy_huge_page() and move it into mm/util.c so it's always
> > available. Fixes an exposure of uninitialised memory on configurations
> > with HUGETLB and UFFD enabled and MIGRATION disabled.
>
> Wait. Exposing uninitialized memory is serious. Can we please include
> full info on this flaw and decide whether a -stable backport is justified?
> If not, why not, etc?
Well, the code was only merged this merge window, so as long as it goes
in in the next few weeks, there's no need to trouble -stable with it.
On Tue, Jul 13, 2021 at 7:21 PM Matthew Wilcox <[email protected]> wrote:
>
> Well, the code was only merged this merge window, so as long as it goes
> in in the next few weeks, there's no need to trouble -stable with it.
It already went in on Monday as commit 79789db03fdd.
Linus