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? > reported-by: Hanjun Guo <guohanjun@xxxxxxxxxx> > Signed-off-by: Jiankang Chen <chenjiankang1@xxxxxxxxxx> > --- > mm/page_alloc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 77e4d3c..5a7c432 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4240,7 +4240,7 @@ unsigned long __get_free_pages(gfp_t gfp_mask, unsigned int order) > struct page *page; > > /* > - * __get_free_pages() returns a 32-bit address, which cannot represent > + * __get_free_pages() returns a virtual address, which cannot represent > * a highmem page > */ > VM_BUG_ON((gfp_mask & __GFP_HIGHMEM) != 0); > -- > 1.7.12.4 > -- 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>
