From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751940AbdF3HVu (ORCPT ); Fri, 30 Jun 2017 03:21:50 -0400 Received: from mx2.suse.de ([195.135.220.15]:54971 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751896AbdF3HVs (ORCPT ); Fri, 30 Jun 2017 03:21:48 -0400 Date: Fri, 30 Jun 2017 09:21:43 +0200 From: Michal Hocko To: Mikulas Patocka Cc: Alexei Starovoitov , Daniel Borkmann , Andrew Morton , Stephen Rothwell , Vlastimil Babka , Andreas Dilger , John Hubbard , David Miller , linux-kernel@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org Subject: Re: [PATCH] mm: convert three more cases to kvmalloc Message-ID: <20170630072142.GA19931@dhcp22.suse.cz> References: <20170629071046.GA31603@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 29-06-17 22:13:26, Mikulas Patocka wrote: > > > On Thu, 29 Jun 2017, Michal Hocko wrote: [...] > > > Index: linux-2.6/kernel/bpf/syscall.c > > > =================================================================== > > > --- linux-2.6.orig/kernel/bpf/syscall.c > > > +++ linux-2.6/kernel/bpf/syscall.c > > > @@ -58,16 +58,7 @@ void *bpf_map_area_alloc(size_t size) > > > * trigger under memory pressure as we really just want to > > > * fail instead. > > > */ > > > - const gfp_t flags = __GFP_NOWARN | __GFP_NORETRY | __GFP_ZERO; > > > - void *area; > > > - > > > - if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) { > > > - area = kmalloc(size, GFP_USER | flags); > > > - if (area != NULL) > > > - return area; > > > - } > > > - > > > - return __vmalloc(size, GFP_KERNEL | flags, PAGE_KERNEL); > > > + return kvmalloc(size, GFP_USER | __GFP_NOWARN | __GFP_NORETRY | __GFP_ZERO); > > > > kvzalloc without additional flags would be more appropriate. > > __GFP_NORETRY is explicitly documented as non-supported > > How is __GFP_NORETRY non-supported? Because its semantic cannot be guaranteed throughout the alloaction stack. vmalloc will ignore it e.g. for page table allocations. > > and NOWARN wouldn't be applied everywhere in the vmalloc path. > > __GFP_NORETRY and __GFP_NOWARN wouldn't be applied in the page-table > allocation and they would be applied in the page allocation - that seems > acceptable. This is rather muddy semantic to me. Both page table and the page is an order-0 allocation. Page table allocations are much less likely but I've explicitly documented that explicit __GFP_NORETRY is unsupported. Slab allocation is already __GFP_NORETRY (unless you specify __GFP_RETRY_MAYFAIL in the current mmotm tree). -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Hocko Subject: Re: [PATCH] mm: convert three more cases to kvmalloc Date: Fri, 30 Jun 2017 09:21:43 +0200 Message-ID: <20170630072142.GA19931@dhcp22.suse.cz> References: <20170629071046.GA31603@dhcp22.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexei Starovoitov , Daniel Borkmann , Andrew Morton , Stephen Rothwell , Vlastimil Babka , Andreas Dilger , John Hubbard , David Miller , linux-kernel@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org To: Mikulas Patocka Return-path: Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-Id: netdev.vger.kernel.org On Thu 29-06-17 22:13:26, Mikulas Patocka wrote: > > > On Thu, 29 Jun 2017, Michal Hocko wrote: [...] > > > Index: linux-2.6/kernel/bpf/syscall.c > > > =================================================================== > > > --- linux-2.6.orig/kernel/bpf/syscall.c > > > +++ linux-2.6/kernel/bpf/syscall.c > > > @@ -58,16 +58,7 @@ void *bpf_map_area_alloc(size_t size) > > > * trigger under memory pressure as we really just want to > > > * fail instead. > > > */ > > > - const gfp_t flags = __GFP_NOWARN | __GFP_NORETRY | __GFP_ZERO; > > > - void *area; > > > - > > > - if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) { > > > - area = kmalloc(size, GFP_USER | flags); > > > - if (area != NULL) > > > - return area; > > > - } > > > - > > > - return __vmalloc(size, GFP_KERNEL | flags, PAGE_KERNEL); > > > + return kvmalloc(size, GFP_USER | __GFP_NOWARN | __GFP_NORETRY | __GFP_ZERO); > > > > kvzalloc without additional flags would be more appropriate. > > __GFP_NORETRY is explicitly documented as non-supported > > How is __GFP_NORETRY non-supported? Because its semantic cannot be guaranteed throughout the alloaction stack. vmalloc will ignore it e.g. for page table allocations. > > and NOWARN wouldn't be applied everywhere in the vmalloc path. > > __GFP_NORETRY and __GFP_NOWARN wouldn't be applied in the page-table > allocation and they would be applied in the page allocation - that seems > acceptable. This is rather muddy semantic to me. Both page table and the page is an order-0 allocation. Page table allocations are much less likely but I've explicitly documented that explicit __GFP_NORETRY is unsupported. Slab allocation is already __GFP_NORETRY (unless you specify __GFP_RETRY_MAYFAIL in the current mmotm tree). -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org