From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751141AbdFBHuQ (ORCPT ); Fri, 2 Jun 2017 03:50:16 -0400 Received: from mx2.suse.de ([195.135.220.15]:44252 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750747AbdFBHuP (ORCPT ); Fri, 2 Jun 2017 03:50:15 -0400 Date: Fri, 2 Jun 2017 09:50:12 +0200 From: Michal Hocko To: "Levin, Alexander (Sasha Levin)" Cc: Andrew Morton , "linux-mm@kvack.org" , LKML , John Hubbard , Andreas Dilger , Vlastimil Babka Subject: Re: [PATCH 1/9] mm: introduce kv[mz]alloc helpers Message-ID: <20170602075012.GC29840@dhcp22.suse.cz> References: <20170306103032.2540-1-mhocko@kernel.org> <20170306103032.2540-2-mhocko@kernel.org> <20170602071718.zk3ujm64xesoqyrr@sasha-lappy> <20170602072855.GB29840@dhcp22.suse.cz> <20170602074008.wctxj5il3rqnnpbf@sasha-lappy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170602074008.wctxj5il3rqnnpbf@sasha-lappy> 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 Fri 02-06-17 07:40:12, Sasha Levin wrote: > On Fri, Jun 02, 2017 at 09:28:56AM +0200, Michal Hocko wrote: > > On Fri 02-06-17 07:17:22, Sasha Levin wrote: > > > On Mon, Mar 06, 2017 at 11:30:24AM +0100, Michal Hocko wrote: > > > > +void *kvmalloc_node(size_t size, gfp_t flags, int node) > > > > +{ > > > > + gfp_t kmalloc_flags = flags; > > > > + void *ret; > > > > + > > > > + /* > > > > + * vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables) > > > > + * so the given set of flags has to be compatible. > > > > + */ > > > > + WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL); > > > > > > Hm, there are quite a few locations in the kernel that do something like: > > > > > > __vmalloc(len, GFP_NOFS, PAGE_KERNEL); > > > > > > According to your patch, vmalloc can't really do GFP_NOFS, right? > > > > Yes. It is quite likely that they will just work because the hardcoded > > GFP_KERNEL inside the vmalloc path is in unlikely paths (page table > > allocations for example) but yes they are broken. I didn't convert some > > places which opencode the kvmalloc with GFP_NOFS because I strongly > > _believe_ that the GFP_NOFS should be revisited, checked whether it is > > needed, documented if so and then memalloc_nofs__{save,restore} be used > > for the scope which is reclaim recursion unsafe. This would turn all > > those vmalloc users to the default GFP_KERNEL and still do the right > > thing. > > While you haven't converted those paths, other folks have picked up > on that: > > commit beeeccca9bebcec386cc31c250cff8a06cf27034 > Author: Vinnie Magro > Date: Thu May 25 12:18:02 2017 -0700 > > btrfs: Use kvzalloc instead of kzalloc/vmalloc in alloc_bitmap > [...] > > Maybe we should make kvmalloc_node() fail non-GFP_KERNEL allocations > rather than just warn on them to make this error more evident? The above has been already discussed [1] and will be dropped with a more appropriate alternative. I do not think we should be failing those, though. Supported flags are documented and the warn on will tell that something is clearly wrong. > I'm not sure how these warnings were missed during testing. I suspect this conversion just hasn't been tested because it is an "obvious cleanup" [1] http://lkml.kernel.org/r/20170531063033.GC1795@yexl-desktop -- Michal Hocko SUSE Labs