On Mon 27-11-17 12:33:41, Michal Hocko wrote:
> On Mon 27-11-17 19:09:24, JianKang Chen wrote:
> > From: Jiankang Chen <chenjianka...@huawei.com>
> >
> > __get_free_pages will return an virtual address,
> > but it is not just 32-bit address, for example a 64-bit system.
> > And this comment really confuse new bigenner of mm.
>
> s@bigenner@beginner@
>
> Anyway, do we really need a bug on for this? Has this actually caught
> any wrong usage? VM_BUG_ON tends to be enabled these days AFAIK and
> panicking the kernel seems like an over-reaction. If there is a real
> risk then why don't we simply mask __GFP_HIGHMEM off when calling
> alloc_pages?
I meant this
---
>From 000bb422fe07adbfa8cd8ed953b18f48647a45d6 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mho...@suse.com>
Date: Wed, 29 Nov 2017 17:02:33 +0100
Subject: [PATCH] mm: drop VM_BUG_ON from __get_free_pages
There is no real reason to blow up just because the caller doesn't know
that __get_free_pages cannot return highmem pages. Simply fix that up
silently. Even if we have some confused users such a fixup will not be
harmful.
Signed-off-by: Michal Hocko <mho...@suse.com>
---
mm/page_alloc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 0d518e9b2ee8..3dd960ea8c13 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4284,9 +4284,7 @@ unsigned long __get_free_pages(gfp_t gfp_mask, unsigned
int order)
* __get_free_pages() returns a virtual address, which cannot represent
* a highmem page
*/
- VM_BUG_ON((gfp_mask & __GFP_HIGHMEM) != 0);
-
- page = alloc_pages(gfp_mask, order);
+ page = alloc_pages(gfp_mask & ~__GFP_HIGHMEM, order);
if (!page)
return 0;
return (unsigned long) page_address(page);
--
2.15.0
--
Michal Hocko
SUSE Labs
