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 <chenjiankang1@xxxxxxxxxx> > > > > __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 <mhocko@xxxxxxxx> 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 <mhocko@xxxxxxxx> --- 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
