lkml.org 
[lkml]   [2017]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH resend] mm/page_alloc: fix comment is __get_free_pages
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@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 <mhocko@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 <mhocko@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

\
 
 \ /
  Last update: 2017-11-29 17:06    [W:0.745 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site