Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759400AbbDYNnl (ORCPT ); Sat, 25 Apr 2015 09:43:41 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:36143 "EHLO mail-wi0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756799AbbDYNnk (ORCPT ); Sat, 25 Apr 2015 09:43:40 -0400 MIME-Version: 1.0 In-Reply-To: References: <1429909549-11726-1-git-send-email-anisse@astier.eu> <1429909549-11726-2-git-send-email-anisse@astier.eu> From: Anisse Astier Date: Sat, 25 Apr 2015 15:43:18 +0200 Message-ID: Subject: Re: [PATCH 1/2] mm/page_alloc.c: cleanup obsolete KM_USER* To: David Rientjes Cc: Andrew Morton , Mel Gorman , "Kirill A. Shutemov" , Alan Cox , Linus Torvalds , Peter Zijlstra , PaX Team , Brad Spengler , Kees Cook , linux-mm@kvack.org, Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2072 Lines: 53 Hi David, First of all, thanks a lot for your time reviewing this series. On Fri, Apr 24, 2015 at 11:36 PM, David Rientjes wrote: > On Fri, 24 Apr 2015, Anisse Astier wrote: > >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index ebffa0e..05fcec9 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -380,16 +380,10 @@ void prep_compound_page(struct page *page, unsigned long order) >> } >> } >> >> -static inline void prep_zero_page(struct page *page, unsigned int order, >> - gfp_t gfp_flags) >> +static inline void zero_pages(struct page *page, unsigned int order) >> { >> int i; >> >> - /* >> - * clear_highpage() will use KM_USER0, so it's a bug to use __GFP_ZERO >> - * and __GFP_HIGHMEM from hard or soft interrupt context. >> - */ >> - VM_BUG_ON((gfp_flags & __GFP_HIGHMEM) && in_interrupt()); >> for (i = 0; i < (1 << order); i++) >> clear_highpage(page + i); >> } >> @@ -975,7 +969,7 @@ static int prep_new_page(struct page *page, unsigned int order, gfp_t gfp_flags, >> kasan_alloc_pages(page, order); >> >> if (gfp_flags & __GFP_ZERO) >> - prep_zero_page(page, order, gfp_flags); >> + zero_pages(page, order); >> >> if (order && (gfp_flags & __GFP_COMP)) >> prep_compound_page(page, order); > > No objection to removing the VM_BUG_ON() here, but I'm not sure that we > need an inline function to do this and to add additional callers in your > next patch. Why can't we just remove the helper entirely and do the > iteration in prep_new_page()? We iterate pages all the time. I just felt it was easier to read as a whole; unless anyone else objects, I think I'll keep it as-is in the next iteration. Anisse -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/