Re: [PATCH 1/9] mm: introduce kv[mz]alloc helpers
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
Re: [PATCH 1/9] mm: introduce kv[mz]alloc helpers
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
Re: [PATCH 1/9] mm: introduce kv[mz]alloc helpers
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 MagroDate: 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? I'm not sure how these warnings were missed during testing. -- Thanks, Sasha
Re: [PATCH 1/9] mm: introduce kv[mz]alloc helpers
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? I'm not sure how these warnings were missed during testing. -- Thanks, Sasha
Re: [PATCH 1/9] mm: introduce kv[mz]alloc helpers
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. -- Michal Hocko SUSE Labs
Re: [PATCH 1/9] mm: introduce kv[mz]alloc helpers
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. -- Michal Hocko SUSE Labs
Re: [PATCH 1/9] mm: introduce kv[mz]alloc helpers
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? -- Thanks, Sasha
Re: [PATCH 1/9] mm: introduce kv[mz]alloc helpers
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? -- Thanks, Sasha