* Re: [PATCH 26/28] arm64: use __vmalloc_node in arch_alloc_vmap_stack [not found] ` <20200408115926.1467567-27-hch@lst.de> @ 2020-04-08 12:18 ` Mark Rutland 0 siblings, 0 replies; 36+ messages in thread From: Mark Rutland @ 2020-04-08 12:18 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, Minchan Kim, iommu, james.morse, Sakari Ailus, Andrew Morton, linuxppc-dev On Wed, Apr 08, 2020 at 01:59:24PM +0200, Christoph Hellwig wrote: > arch_alloc_vmap_stack can use a slightly higher level vmalloc function. > > Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Mark Rutland <mark.rutland@arm.com> Mark. > --- > arch/arm64/include/asm/vmap_stack.h | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/include/asm/vmap_stack.h b/arch/arm64/include/asm/vmap_stack.h > index 0a12115d9638..0cc6636e3f15 100644 > --- a/arch/arm64/include/asm/vmap_stack.h > +++ b/arch/arm64/include/asm/vmap_stack.h > @@ -19,10 +19,8 @@ static inline unsigned long *arch_alloc_vmap_stack(size_t stack_size, int node) > { > BUILD_BUG_ON(!IS_ENABLED(CONFIG_VMAP_STACK)); > > - return __vmalloc_node_range(stack_size, THREAD_ALIGN, > - VMALLOC_START, VMALLOC_END, > - THREADINFO_GFP, PAGE_KERNEL, 0, node, > - __builtin_return_address(0)); > + return __vmalloc_node(stack_size, THREAD_ALIGN, THREADINFO_GFP, node, > + __builtin_return_address(0)); > } > > #endif /* __ASM_VMAP_STACK_H */ > -- > 2.25.1 > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <20200408115926.1467567-18-hch@lst.de>]
* Re: [PATCH 17/28] mm: remove the prot argument from vm_map_ram [not found] ` <20200408115926.1467567-18-hch@lst.de> @ 2020-04-08 12:21 ` Peter Zijlstra 2020-04-09 0:39 ` Gao Xiang 1 sibling, 0 replies; 36+ messages in thread From: Peter Zijlstra @ 2020-04-08 12:21 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On Wed, Apr 08, 2020 at 01:59:15PM +0200, Christoph Hellwig wrote: > This is always GFP_KERNEL - for long term mappings with other properties > vmap should be used. PAGE_KERNEL != GFP_KERNEL :-) > - return vm_map_ram(mock->pages, mock->npages, 0, PAGE_KERNEL); > + return vm_map_ram(mock->pages, mock->npages, 0); _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 17/28] mm: remove the prot argument from vm_map_ram [not found] ` <20200408115926.1467567-18-hch@lst.de> 2020-04-08 12:21 ` [PATCH 17/28] mm: remove the prot argument from vm_map_ram Peter Zijlstra @ 2020-04-09 0:39 ` Gao Xiang 1 sibling, 0 replies; 36+ messages in thread From: Gao Xiang @ 2020-04-09 0:39 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On Wed, Apr 08, 2020 at 01:59:15PM +0200, Christoph Hellwig wrote: > This is always GFP_KERNEL - for long term mappings with other properties > vmap should be used. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 2 +- > drivers/media/common/videobuf2/videobuf2-dma-sg.c | 3 +-- > drivers/media/common/videobuf2/videobuf2-vmalloc.c | 3 +-- > fs/erofs/decompressor.c | 2 +- For EROFS part, Acked-by: Gao Xiang <xiang@kernel.org> Thanks, Gao Xiang _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: decruft the vmalloc API [not found] <20200408115926.1467567-1-hch@lst.de> [not found] ` <20200408115926.1467567-27-hch@lst.de> [not found] ` <20200408115926.1467567-18-hch@lst.de> @ 2020-04-08 12:25 ` Peter Zijlstra [not found] ` <20200408115926.1467567-20-hch@lst.de> ` (11 subsequent siblings) 14 siblings, 0 replies; 36+ messages in thread From: Peter Zijlstra @ 2020-04-08 12:25 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On Wed, Apr 08, 2020 at 01:58:58PM +0200, Christoph Hellwig wrote: > Hi all, > > Peter noticed that with some dumb luck you can toast the kernel address > space with exported vmalloc symbols. > > I used this as an opportunity to decruft the vmalloc.c API and make it > much more systematic. This also removes any chance to create vmalloc > mappings outside the designated areas or using executable permissions > from modules. Besides that it removes more than 300 lines of code. > Looks great, thanks for doing this! Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <20200408115926.1467567-20-hch@lst.de>]
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc [not found] ` <20200408115926.1467567-20-hch@lst.de> @ 2020-04-08 12:25 ` Daniel Vetter 2020-04-09 8:54 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 36+ messages in thread From: Daniel Vetter @ 2020-04-08 12:25 UTC (permalink / raw) To: Christoph Hellwig, Benjamin Herrenschmidt Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote: > If this code was broken for non-coherent caches a crude powerpc hack > isn't going to help anyone else. Remove the hack as it is the last > user of __vmalloc passing a page protection flag other than PAGE_KERNEL. Well Ben added this to make stuff work on ppc, ofc the home grown dma layer in drm from back then isn't going to work in other places. I guess should have at least an ack from him, in case anyone still cares about this on ppc. Adding Ben to cc. -Daniel > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > drivers/gpu/drm/drm_scatter.c | 11 +---------- > 1 file changed, 1 insertion(+), 10 deletions(-) > > diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c > index ca520028b2cb..f4e6184d1877 100644 > --- a/drivers/gpu/drm/drm_scatter.c > +++ b/drivers/gpu/drm/drm_scatter.c > @@ -43,15 +43,6 @@ > > #define DEBUG_SCATTER 0 > > -static inline void *drm_vmalloc_dma(unsigned long size) > -{ > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE) > - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL)); > -#else > - return vmalloc_32(size); > -#endif > -} > - > static void drm_sg_cleanup(struct drm_sg_mem * entry) > { > struct page *page; > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data, > return -ENOMEM; > } > > - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT); > + entry->virtual = vmalloc_32(pages << PAGE_SHIFT); > if (!entry->virtual) { > kfree(entry->busaddr); > kfree(entry->pagelist); > -- > 2.25.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc 2020-04-08 12:25 ` [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc Daniel Vetter @ 2020-04-09 8:54 ` Benjamin Herrenschmidt 2020-04-09 9:41 ` Daniel Vetter 2020-04-09 11:46 ` Gerhard Pircher 0 siblings, 2 replies; 36+ messages in thread From: Benjamin Herrenschmidt @ 2020-04-09 8:54 UTC (permalink / raw) To: Daniel Vetter, Christoph Hellwig Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote: > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote: > > If this code was broken for non-coherent caches a crude powerpc hack > > isn't going to help anyone else. Remove the hack as it is the last > > user of __vmalloc passing a page protection flag other than PAGE_KERNEL. > > Well Ben added this to make stuff work on ppc, ofc the home grown dma > layer in drm from back then isn't going to work in other places. I guess > should have at least an ack from him, in case anyone still cares about > this on ppc. Adding Ben to cc. This was due to some drivers (radeon ?) trying to use vmalloc pages for coherent DMA, which means on those 4xx powerpc's need to be non-cached. There were machines using that (440 based iirc), though I honestly can't tell if anybody still uses any of it. Cheers, Ben. > -Daniel > > > > > Signed-off-by: Christoph Hellwig <hch@lst.de> > > --- > > drivers/gpu/drm/drm_scatter.c | 11 +---------- > > 1 file changed, 1 insertion(+), 10 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c > > index ca520028b2cb..f4e6184d1877 100644 > > --- a/drivers/gpu/drm/drm_scatter.c > > +++ b/drivers/gpu/drm/drm_scatter.c > > @@ -43,15 +43,6 @@ > > > > #define DEBUG_SCATTER 0 > > > > -static inline void *drm_vmalloc_dma(unsigned long size) > > -{ > > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE) > > - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL)); > > -#else > > - return vmalloc_32(size); > > -#endif > > -} > > - > > static void drm_sg_cleanup(struct drm_sg_mem * entry) > > { > > struct page *page; > > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data, > > return -ENOMEM; > > } > > > > - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT); > > + entry->virtual = vmalloc_32(pages << PAGE_SHIFT); > > if (!entry->virtual) { > > kfree(entry->busaddr); > > kfree(entry->pagelist); > > -- > > 2.25.1 > > > > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc 2020-04-09 8:54 ` Benjamin Herrenschmidt @ 2020-04-09 9:41 ` Daniel Vetter 2020-04-09 14:19 ` Alex Deucher 2020-04-09 22:56 ` Benjamin Herrenschmidt 2020-04-09 11:46 ` Gerhard Pircher 1 sibling, 2 replies; 36+ messages in thread From: Daniel Vetter @ 2020-04-09 9:41 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: linux-hyperv, David Airlie, dri-devel, Linux MM, K. Y. Srinivasan, open list:GENERIC INCLUDE/A..., linux-s390, Wei Liu, Stephen Hemminger, X86 ML, Christoph Hellwig, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, moderated list:DMA BUFFER SHARING FRAMEWORK, bpf, Linux ARM, Christophe Leroy, Robin Murphy, Linux Kernel Mailing List, Minchan Kim, list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, , Sakari Ailus, Andrew Morton, linuxppc-dev On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > > On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote: > > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote: > > > If this code was broken for non-coherent caches a crude powerpc hack > > > isn't going to help anyone else. Remove the hack as it is the last > > > user of __vmalloc passing a page protection flag other than PAGE_KERNEL. > > > > Well Ben added this to make stuff work on ppc, ofc the home grown dma > > layer in drm from back then isn't going to work in other places. I guess > > should have at least an ack from him, in case anyone still cares about > > this on ppc. Adding Ben to cc. > > This was due to some drivers (radeon ?) trying to use vmalloc pages for > coherent DMA, which means on those 4xx powerpc's need to be non-cached. > > There were machines using that (440 based iirc), though I honestly > can't tell if anybody still uses any of it. agp subsystem still seems to happily do that (vmalloc memory for device access), never having been ported to dma apis (or well converted to iommu drivers, which they kinda are really). So I think this all still works exactly as back then, even with the kms radeon drivers. Question really is whether we have users left, and I have no clue about that either. Now if these boxes didn't ever have agp then I think we can get away with deleting this, since we've already deleted the legacy radeon driver. And that one used vmalloc for everything. The new kms one does use the dma-api if the gpu isn't connected through agp. -Daniel > Cheers, > Ben. > > > -Daniel > > > > > > > > Signed-off-by: Christoph Hellwig <hch@lst.de> > > > --- > > > drivers/gpu/drm/drm_scatter.c | 11 +---------- > > > 1 file changed, 1 insertion(+), 10 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c > > > index ca520028b2cb..f4e6184d1877 100644 > > > --- a/drivers/gpu/drm/drm_scatter.c > > > +++ b/drivers/gpu/drm/drm_scatter.c > > > @@ -43,15 +43,6 @@ > > > > > > #define DEBUG_SCATTER 0 > > > > > > -static inline void *drm_vmalloc_dma(unsigned long size) > > > -{ > > > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE) > > > - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL)); > > > -#else > > > - return vmalloc_32(size); > > > -#endif > > > -} > > > - > > > static void drm_sg_cleanup(struct drm_sg_mem * entry) > > > { > > > struct page *page; > > > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data, > > > return -ENOMEM; > > > } > > > > > > - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT); > > > + entry->virtual = vmalloc_32(pages << PAGE_SHIFT); > > > if (!entry->virtual) { > > > kfree(entry->busaddr); > > > kfree(entry->pagelist); > > > -- > > > 2.25.1 > > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc 2020-04-09 9:41 ` Daniel Vetter @ 2020-04-09 14:19 ` Alex Deucher 2020-04-09 14:57 ` Daniel Vetter 2020-04-09 22:56 ` Benjamin Herrenschmidt 1 sibling, 1 reply; 36+ messages in thread From: Alex Deucher @ 2020-04-09 14:19 UTC (permalink / raw) To: Daniel Vetter Cc: linux-hyperv, David Airlie, dri-devel, Linux MM, K. Y. Srinivasan, Christoph Hellwig, open list:GENERIC INCLUDE/A..., linux-s390, Wei Liu, Stephen Hemminger, X86 ML, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, moderated list:DMA BUFFER SHARING FRAMEWORK, Andrew Morton, Linux ARM, Christophe Leroy, linuxppc-dev, Linux Kernel Mailing List, Minchan Kim, list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, , Sakari Ailus, bpf, Robin Murphy On Thu, Apr 9, 2020 at 5:41 AM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt > <benh@kernel.crashing.org> wrote: > > > > On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote: > > > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote: > > > > If this code was broken for non-coherent caches a crude powerpc hack > > > > isn't going to help anyone else. Remove the hack as it is the last > > > > user of __vmalloc passing a page protection flag other than PAGE_KERNEL. > > > > > > Well Ben added this to make stuff work on ppc, ofc the home grown dma > > > layer in drm from back then isn't going to work in other places. I guess > > > should have at least an ack from him, in case anyone still cares about > > > this on ppc. Adding Ben to cc. > > > > This was due to some drivers (radeon ?) trying to use vmalloc pages for > > coherent DMA, which means on those 4xx powerpc's need to be non-cached. > > > > There were machines using that (440 based iirc), though I honestly > > can't tell if anybody still uses any of it. > > agp subsystem still seems to happily do that (vmalloc memory for > device access), never having been ported to dma apis (or well > converted to iommu drivers, which they kinda are really). So I think > this all still works exactly as back then, even with the kms radeon > drivers. Question really is whether we have users left, and I have no > clue about that either. > > Now if these boxes didn't ever have agp then I think we can get away > with deleting this, since we've already deleted the legacy radeon > driver. And that one used vmalloc for everything. The new kms one does > use the dma-api if the gpu isn't connected through agp. All radeons have a built in remapping table to handle non-AGP systems. On the earlier radeons it wasn't quite as performant as AGP, but it was always more reliable because AGP is AGP. Maybe it's time to let AGP go? Alex > -Daniel > > > Cheers, > > Ben. > > > > > -Daniel > > > > > > > > > > > Signed-off-by: Christoph Hellwig <hch@lst.de> > > > > --- > > > > drivers/gpu/drm/drm_scatter.c | 11 +---------- > > > > 1 file changed, 1 insertion(+), 10 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c > > > > index ca520028b2cb..f4e6184d1877 100644 > > > > --- a/drivers/gpu/drm/drm_scatter.c > > > > +++ b/drivers/gpu/drm/drm_scatter.c > > > > @@ -43,15 +43,6 @@ > > > > > > > > #define DEBUG_SCATTER 0 > > > > > > > > -static inline void *drm_vmalloc_dma(unsigned long size) > > > > -{ > > > > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE) > > > > - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL)); > > > > -#else > > > > - return vmalloc_32(size); > > > > -#endif > > > > -} > > > > - > > > > static void drm_sg_cleanup(struct drm_sg_mem * entry) > > > > { > > > > struct page *page; > > > > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data, > > > > return -ENOMEM; > > > > } > > > > > > > > - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT); > > > > + entry->virtual = vmalloc_32(pages << PAGE_SHIFT); > > > > if (!entry->virtual) { > > > > kfree(entry->busaddr); > > > > kfree(entry->pagelist); > > > > -- > > > > 2.25.1 > > > > > > > > > > > > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc 2020-04-09 14:19 ` Alex Deucher @ 2020-04-09 14:57 ` Daniel Vetter 0 siblings, 0 replies; 36+ messages in thread From: Daniel Vetter @ 2020-04-09 14:57 UTC (permalink / raw) To: Alex Deucher Cc: linux-hyperv, David Airlie, dri-devel, Linux MM, K. Y. Srinivasan, Christoph Hellwig, open list:GENERIC INCLUDE/A..., linux-s390, Wei Liu, Stephen Hemminger, X86 ML, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, moderated list:DMA BUFFER SHARING FRAMEWORK, Andrew Morton, Linux ARM, Christophe Leroy, linuxppc-dev, Linux Kernel Mailing List, Minchan Kim, list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, , Sakari Ailus, bpf, Robin Murphy On Thu, Apr 9, 2020 at 4:19 PM Alex Deucher <alexdeucher@gmail.com> wrote: > > On Thu, Apr 9, 2020 at 5:41 AM Daniel Vetter <daniel@ffwll.ch> wrote: > > > > On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt > > <benh@kernel.crashing.org> wrote: > > > > > > On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote: > > > > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote: > > > > > If this code was broken for non-coherent caches a crude powerpc hack > > > > > isn't going to help anyone else. Remove the hack as it is the last > > > > > user of __vmalloc passing a page protection flag other than PAGE_KERNEL. > > > > > > > > Well Ben added this to make stuff work on ppc, ofc the home grown dma > > > > layer in drm from back then isn't going to work in other places. I guess > > > > should have at least an ack from him, in case anyone still cares about > > > > this on ppc. Adding Ben to cc. > > > > > > This was due to some drivers (radeon ?) trying to use vmalloc pages for > > > coherent DMA, which means on those 4xx powerpc's need to be non-cached. > > > > > > There were machines using that (440 based iirc), though I honestly > > > can't tell if anybody still uses any of it. > > > > agp subsystem still seems to happily do that (vmalloc memory for > > device access), never having been ported to dma apis (or well > > converted to iommu drivers, which they kinda are really). So I think > > this all still works exactly as back then, even with the kms radeon > > drivers. Question really is whether we have users left, and I have no > > clue about that either. > > > > Now if these boxes didn't ever have agp then I think we can get away > > with deleting this, since we've already deleted the legacy radeon > > driver. And that one used vmalloc for everything. The new kms one does > > use the dma-api if the gpu isn't connected through agp. > > All radeons have a built in remapping table to handle non-AGP systems. > On the earlier radeons it wasn't quite as performant as AGP, but it > was always more reliable because AGP is AGP. Maybe it's time to let > AGP go? I'd be very much in favour of that, if we can just use the integrated gart and drop agp fast writes wobbliness on the floor. I think the only other modern driver using agp would be nouveau at that point. -Daniel > > Alex > > > -Daniel > > > > > Cheers, > > > Ben. > > > > > > > -Daniel > > > > > > > > > > > > > > Signed-off-by: Christoph Hellwig <hch@lst.de> > > > > > --- > > > > > drivers/gpu/drm/drm_scatter.c | 11 +---------- > > > > > 1 file changed, 1 insertion(+), 10 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c > > > > > index ca520028b2cb..f4e6184d1877 100644 > > > > > --- a/drivers/gpu/drm/drm_scatter.c > > > > > +++ b/drivers/gpu/drm/drm_scatter.c > > > > > @@ -43,15 +43,6 @@ > > > > > > > > > > #define DEBUG_SCATTER 0 > > > > > > > > > > -static inline void *drm_vmalloc_dma(unsigned long size) > > > > > -{ > > > > > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE) > > > > > - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL)); > > > > > -#else > > > > > - return vmalloc_32(size); > > > > > -#endif > > > > > -} > > > > > - > > > > > static void drm_sg_cleanup(struct drm_sg_mem * entry) > > > > > { > > > > > struct page *page; > > > > > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data, > > > > > return -ENOMEM; > > > > > } > > > > > > > > > > - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT); > > > > > + entry->virtual = vmalloc_32(pages << PAGE_SHIFT); > > > > > if (!entry->virtual) { > > > > > kfree(entry->busaddr); > > > > > kfree(entry->pagelist); > > > > > -- > > > > > 2.25.1 > > > > > > > > > > > > > > > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc 2020-04-09 9:41 ` Daniel Vetter 2020-04-09 14:19 ` Alex Deucher @ 2020-04-09 22:56 ` Benjamin Herrenschmidt 2020-04-10 8:11 ` Daniel Vetter 1 sibling, 1 reply; 36+ messages in thread From: Benjamin Herrenschmidt @ 2020-04-09 22:56 UTC (permalink / raw) To: Daniel Vetter Cc: linux-hyperv, David Airlie, dri-devel, Linux MM, K. Y. Srinivasan, open list:GENERIC INCLUDE/A..., linux-s390, Wei Liu, Stephen Hemminger, X86 ML, Christoph Hellwig, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, moderated list:DMA BUFFER SHARING FRAMEWORK, bpf, Linux ARM, Christophe Leroy, Robin Murphy, Linux Kernel Mailing List, Minchan Kim, list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, , Sakari Ailus, Andrew Morton, linuxppc-dev On Thu, 2020-04-09 at 11:41 +0200, Daniel Vetter wrote: > Now if these boxes didn't ever have agp then I think we can get away > with deleting this, since we've already deleted the legacy radeon > driver. And that one used vmalloc for everything. The new kms one does > use the dma-api if the gpu isn't connected through agp Definitely no AGP there. Cheers Ben. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc 2020-04-09 22:56 ` Benjamin Herrenschmidt @ 2020-04-10 8:11 ` Daniel Vetter 0 siblings, 0 replies; 36+ messages in thread From: Daniel Vetter @ 2020-04-10 8:11 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: linux-hyperv, David Airlie, dri-devel, Linux MM, K. Y. Srinivasan, open list:GENERIC INCLUDE/A..., linux-s390, Wei Liu, Stephen Hemminger, X86 ML, Christoph Hellwig, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, moderated list:DMA BUFFER SHARING FRAMEWORK, bpf, Linux ARM, Christophe Leroy, Robin Murphy, Linux Kernel Mailing List, Minchan Kim, list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, , Sakari Ailus, Andrew Morton, linuxppc-dev On Fri, Apr 10, 2020 at 12:57 AM Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > > On Thu, 2020-04-09 at 11:41 +0200, Daniel Vetter wrote: > > Now if these boxes didn't ever have agp then I think we can get away > > with deleting this, since we've already deleted the legacy radeon > > driver. And that one used vmalloc for everything. The new kms one does > > use the dma-api if the gpu isn't connected through agp > > Definitely no AGP there. Ah in that case I think we can be sure that this code is dead. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc 2020-04-09 8:54 ` Benjamin Herrenschmidt 2020-04-09 9:41 ` Daniel Vetter @ 2020-04-09 11:46 ` Gerhard Pircher 1 sibling, 0 replies; 36+ messages in thread From: Gerhard Pircher @ 2020-04-09 11:46 UTC (permalink / raw) To: Benjamin Herrenschmidt, Daniel Vetter, Christoph Hellwig Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, Andrew Morton, linux-arm-kernel, linuxppc-dev, linux-kernel, Minchan Kim, iommu, Sakari Ailus, bpf, Robin Murphy Am 09.04.20 um 10:54 schrieb Benjamin Herrenschmidt: > On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote: >> On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote: >>> If this code was broken for non-coherent caches a crude powerpc hack >>> isn't going to help anyone else. Remove the hack as it is the last >>> user of __vmalloc passing a page protection flag other than PAGE_KERNEL. >> >> Well Ben added this to make stuff work on ppc, ofc the home grown dma >> layer in drm from back then isn't going to work in other places. I guess >> should have at least an ack from him, in case anyone still cares about >> this on ppc. Adding Ben to cc. > > This was due to some drivers (radeon ?) trying to use vmalloc pages for > coherent DMA, which means on those 4xx powerpc's need to be non-cached. > > There were machines using that (440 based iirc), though I honestly > can't tell if anybody still uses any of it. The first-gen amigaone platform (6xx/book32s) uses the radeon driver together with non-coherent DMA. However this only ever worked reliably for DRI1. br, Gerhard > Cheers, > Ben. > >> -Daniel >> >>> >>> Signed-off-by: Christoph Hellwig <hch@lst.de> >>> --- >>> drivers/gpu/drm/drm_scatter.c | 11 +---------- >>> 1 file changed, 1 insertion(+), 10 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c >>> index ca520028b2cb..f4e6184d1877 100644 >>> --- a/drivers/gpu/drm/drm_scatter.c >>> +++ b/drivers/gpu/drm/drm_scatter.c >>> @@ -43,15 +43,6 @@ >>> >>> #define DEBUG_SCATTER 0 >>> >>> -static inline void *drm_vmalloc_dma(unsigned long size) >>> -{ >>> -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE) >>> - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL)); >>> -#else >>> - return vmalloc_32(size); >>> -#endif >>> -} >>> - >>> static void drm_sg_cleanup(struct drm_sg_mem * entry) >>> { >>> struct page *page; >>> @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data, >>> return -ENOMEM; >>> } >>> >>> - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT); >>> + entry->virtual = vmalloc_32(pages << PAGE_SHIFT); >>> if (!entry->virtual) { >>> kfree(entry->busaddr); >>> kfree(entry->pagelist); >>> -- >>> 2.25.1 >>> >> >> > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <20200408115926.1467567-19-hch@lst.de>]
* Re: [PATCH 18/28] mm: enforce that vmap can't map pages executable [not found] ` <20200408115926.1467567-19-hch@lst.de> @ 2020-04-08 12:38 ` Mark Rutland 0 siblings, 0 replies; 36+ messages in thread From: Mark Rutland @ 2020-04-08 12:38 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-hyperv, David Airlie, Catalin marinas, dri-devel, linux-mm, K. Y. Srinivasan, Will Deacon, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On Wed, Apr 08, 2020 at 01:59:16PM +0200, Christoph Hellwig wrote: > To help enforcing the W^X protection don't allow remapping existing > pages as executable. > > Based on patch from Peter Zijlstra <peterz@infradead.org>. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > arch/x86/include/asm/pgtable_types.h | 6 ++++++ > include/asm-generic/pgtable.h | 4 ++++ > mm/vmalloc.c | 2 +- > 3 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h > index 947867f112ea..2e7c442cc618 100644 > --- a/arch/x86/include/asm/pgtable_types.h > +++ b/arch/x86/include/asm/pgtable_types.h > @@ -282,6 +282,12 @@ typedef struct pgprot { pgprotval_t pgprot; } pgprot_t; > > typedef struct { pgdval_t pgd; } pgd_t; > > +static inline pgprot_t pgprot_nx(pgprot_t prot) > +{ > + return __pgprot(pgprot_val(prot) | _PAGE_NX); > +} > +#define pgprot_nx pgprot_nx > + > #ifdef CONFIG_X86_PAE I reckon for arm64 we can do similar in our <asm/pgtable.h>: #define pgprot_nx(pgprot_t prot) \ __pgprot_modify(prot, 0, PTE_PXN) ... matching the style of our existing pgprot_*() modifier helpers. Mark. > > /* > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h > index 329b8c8ca703..8c5f9c29698b 100644 > --- a/include/asm-generic/pgtable.h > +++ b/include/asm-generic/pgtable.h > @@ -491,6 +491,10 @@ static inline int arch_unmap_one(struct mm_struct *mm, > #define flush_tlb_fix_spurious_fault(vma, address) flush_tlb_page(vma, address) > #endif > > +#ifndef pgprot_nx > +#define pgprot_nx(prot) (prot) > +#endif > + > #ifndef pgprot_noncached > #define pgprot_noncached(prot) (prot) > #endif > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 7356b3f07bd8..334c75251ddb 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2390,7 +2390,7 @@ void *vmap(struct page **pages, unsigned int count, > if (!area) > return NULL; > > - if (map_kernel_range((unsigned long)area->addr, size, prot, > + if (map_kernel_range((unsigned long)area->addr, size, pgprot_nx(prot), > pages) < 0) { > vunmap(area->addr); > return NULL; > -- > 2.25.1 > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 02/28] staging: android: ion: use vmap instead of vm_map_ram [not found] <20200408115926.1467567-1-hch@lst.de> ` (4 preceding siblings ...) [not found] ` <20200408115926.1467567-19-hch@lst.de> @ 2020-04-08 12:48 ` Hillf Danton [not found] ` <20200408115926.1467567-3-hch@lst.de> ` (8 subsequent siblings) 14 siblings, 0 replies; 36+ messages in thread From: Hillf Danton @ 2020-04-08 12:48 UTC (permalink / raw) To: Christoph Hellwig Cc: Christophe Leroy, linux-arch, linux-hyperv, linux-s390, Peter Zijlstra, syzkaller-bugs, linux-kernel, dri-devel, linaro-mm-sig, linux-mm, iommu, Andrew Morton, linuxppc-dev, bpf, linux-arm-kernel On Wed, 8 Apr 2020 13:59:00 +0200 > > vm_map_ram can keep mappings around after the vm_unmap_ram. Using that > with non-PAGE_KERNEL mappings can lead to all kinds of aliasing issues. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > drivers/staging/android/ion/ion_heap.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/android/ion/ion_heap.c b/drivers/staging/android/ion/ion_heap.c > index 473b465724f1..a2d5c6df4b96 100644 > --- a/drivers/staging/android/ion/ion_heap.c > +++ b/drivers/staging/android/ion/ion_heap.c > @@ -99,12 +99,12 @@ int ion_heap_map_user(struct ion_heap *heap, struct ion_buffer *buffer, > > static int ion_heap_clear_pages(struct page **pages, int num, pgprot_t pgprot) > { > - void *addr = vm_map_ram(pages, num, -1, pgprot); > + void *addr = vmap(pages, num, VM_MAP); A merge glitch? void *vmap(struct page **pages, unsigned int count, unsigned long flags, pgprot_t prot) > > if (!addr) > return -ENOMEM; > memset(addr, 0, PAGE_SIZE * num); > - vm_unmap_ram(addr, num); > + vunmap(addr); > > return 0; > } > -- > 2.25.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <20200408115926.1467567-3-hch@lst.de>]
* Re: [PATCH 02/28] staging: android: ion: use vmap instead of vm_map_ram [not found] ` <20200408115926.1467567-3-hch@lst.de> @ 2020-04-08 13:27 ` Greg KH 0 siblings, 0 replies; 36+ messages in thread From: Greg KH @ 2020-04-08 13:27 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On Wed, Apr 08, 2020 at 01:59:00PM +0200, Christoph Hellwig wrote: > vm_map_ram can keep mappings around after the vm_unmap_ram. Using that > with non-PAGE_KERNEL mappings can lead to all kinds of aliasing issues. > > Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <20200408115926.1467567-28-hch@lst.de>]
* Re: [PATCH 27/28] s390: use __vmalloc_node in alloc_vm_stack [not found] ` <20200408115926.1467567-28-hch@lst.de> @ 2020-04-08 13:33 ` Christian Borntraeger 0 siblings, 0 replies; 36+ messages in thread From: Christian Borntraeger @ 2020-04-08 13:33 UTC (permalink / raw) To: Christoph Hellwig, Andrew Morton, K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Wei Liu, x86, David Airlie, Daniel Vetter, Laura Abbott, Sumit Semwal, Sakari Ailus, Minchan Kim, Nitin Gupta Cc: Christophe Leroy, linux-arch, linux-hyperv, linux-s390, Peter Zijlstra, linuxppc-dev, linux-kernel, dri-devel, linaro-mm-sig, linux-mm, iommu, bpf, Robin Murphy, linux-arm-kernel On 08.04.20 13:59, Christoph Hellwig wrote: > alloc_vm_stack can use a slightly higher level vmalloc function. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > arch/powerpc/kernel/irq.c | 5 ++--- wrong subject (power vs s390) > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c > index a25ed47087ee..4518fb1d6bf4 100644 > --- a/arch/powerpc/kernel/irq.c > +++ b/arch/powerpc/kernel/irq.c > @@ -735,9 +735,8 @@ void do_IRQ(struct pt_regs *regs) > > static void *__init alloc_vm_stack(void) > { > - return __vmalloc_node_range(THREAD_SIZE, THREAD_ALIGN, VMALLOC_START, > - VMALLOC_END, THREADINFO_GFP, PAGE_KERNEL, > - 0, NUMA_NO_NODE, (void*)_RET_IP_); > + return __vmalloc_node(THREAD_SIZE, THREAD_ALIGN, THREADINFO_GFP, > + NUMA_NO_NODE, (void *)_RET_IP_); > } > > static void __init vmap_irqstack_init(void) > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <20200408115926.1467567-29-hch@lst.de>]
* Re: [PATCH 28/28] s390: use __vmalloc_node in stack_alloc [not found] ` <20200408115926.1467567-29-hch@lst.de> @ 2020-04-08 13:44 ` Christian Borntraeger 0 siblings, 0 replies; 36+ messages in thread From: Christian Borntraeger @ 2020-04-08 13:44 UTC (permalink / raw) To: Christoph Hellwig, Andrew Morton, K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Wei Liu, x86, David Airlie, Daniel Vetter, Laura Abbott, Sumit Semwal, Sakari Ailus, Minchan Kim, Nitin Gupta Cc: Christophe Leroy, linux-arch, linux-hyperv, linux-s390, Peter Zijlstra, linuxppc-dev, linux-kernel, dri-devel, linaro-mm-sig, linux-mm, iommu, bpf, Robin Murphy, linux-arm-kernel On 08.04.20 13:59, Christoph Hellwig wrote: > stack_alloc can use a slightly higher level vmalloc function. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > arch/s390/kernel/setup.c | 9 +++------ > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c > index 36445dd40fdb..0f0b140b5558 100644 > --- a/arch/s390/kernel/setup.c > +++ b/arch/s390/kernel/setup.c > @@ -305,12 +305,9 @@ void *restart_stack __section(.data); > unsigned long stack_alloc(void) > { > #ifdef CONFIG_VMAP_STACK > - return (unsigned long) > - __vmalloc_node_range(THREAD_SIZE, THREAD_SIZE, > - VMALLOC_START, VMALLOC_END, > - THREADINFO_GFP, > - PAGE_KERNEL, 0, NUMA_NO_NODE, > - __builtin_return_address(0)); > + return (unsigned long)__vmalloc_node(THREAD_SIZE, THREAD_SIZE, > + THREADINFO_GFP, NUMA_NO_NODE, > + __builtin_return_address(0)); Looks sane. Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> > #else > return __get_free_pages(GFP_KERNEL, THREAD_SIZE_ORDER); > #endif > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <20200408115926.1467567-10-hch@lst.de>]
* Re: [PATCH 09/28] mm: rename CONFIG_PGTABLE_MAPPING to CONFIG_ZSMALLOC_PGTABLE_MAPPING [not found] ` <20200408115926.1467567-10-hch@lst.de> @ 2020-04-08 15:00 ` Randy Dunlap 2020-04-09 15:59 ` Minchan Kim 1 sibling, 0 replies; 36+ messages in thread From: Randy Dunlap @ 2020-04-08 15:00 UTC (permalink / raw) To: Christoph Hellwig, Andrew Morton, K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Wei Liu, x86, David Airlie, Daniel Vetter, Laura Abbott, Sumit Semwal, Sakari Ailus, Minchan Kim, Nitin Gupta Cc: Christophe Leroy, linux-arch, linux-hyperv, linux-s390, Peter Zijlstra, linuxppc-dev, linux-kernel, dri-devel, linaro-mm-sig, linux-mm, iommu, bpf, Robin Murphy, linux-arm-kernel On 4/8/20 4:59 AM, Christoph Hellwig wrote: > Rename the Kconfig variable to clarify the scope. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > arch/arm/configs/omap2plus_defconfig | 2 +- > include/linux/zsmalloc.h | 2 +- > mm/Kconfig | 2 +- > mm/zsmalloc.c | 8 ++++---- > 4 files changed, 7 insertions(+), 7 deletions(-) > Looks good. Thanks. Acked-by: Randy Dunlap <rdunlap@infradead.org> -- ~Randy _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 09/28] mm: rename CONFIG_PGTABLE_MAPPING to CONFIG_ZSMALLOC_PGTABLE_MAPPING [not found] ` <20200408115926.1467567-10-hch@lst.de> 2020-04-08 15:00 ` [PATCH 09/28] mm: rename CONFIG_PGTABLE_MAPPING to CONFIG_ZSMALLOC_PGTABLE_MAPPING Randy Dunlap @ 2020-04-09 15:59 ` Minchan Kim 1 sibling, 0 replies; 36+ messages in thread From: Minchan Kim @ 2020-04-09 15:59 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On Wed, Apr 08, 2020 at 01:59:07PM +0200, Christoph Hellwig wrote: > Rename the Kconfig variable to clarify the scope. > > Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Minchan Kim <minchan@kernel.org> _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <20200408115926.1467567-11-hch@lst.de>]
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc [not found] ` <20200408115926.1467567-11-hch@lst.de> @ 2020-04-08 15:01 ` Randy Dunlap 2020-04-08 15:12 ` Peter Zijlstra 2020-04-09 16:08 ` Minchan Kim 1 sibling, 1 reply; 36+ messages in thread From: Randy Dunlap @ 2020-04-08 15:01 UTC (permalink / raw) To: Christoph Hellwig, Andrew Morton, K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Wei Liu, x86, David Airlie, Daniel Vetter, Laura Abbott, Sumit Semwal, Sakari Ailus, Minchan Kim, Nitin Gupta Cc: Christophe Leroy, linux-arch, linux-hyperv, linux-s390, Peter Zijlstra, linuxppc-dev, linux-kernel, dri-devel, linaro-mm-sig, linux-mm, iommu, bpf, Robin Murphy, linux-arm-kernel Hi, On 4/8/20 4:59 AM, Christoph Hellwig wrote: > diff --git a/mm/Kconfig b/mm/Kconfig > index 36949a9425b8..614cc786b519 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -702,7 +702,7 @@ config ZSMALLOC > > config ZSMALLOC_PGTABLE_MAPPING > bool "Use page table mapping to access object in zsmalloc" > - depends on ZSMALLOC > + depends on ZSMALLOC=y It's a bool so this shouldn't matter... not needed. > help > By default, zsmalloc uses a copy-based object mapping method to > access allocations that span two pages. However, if a particular -- ~Randy _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc 2020-04-08 15:01 ` [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc Randy Dunlap @ 2020-04-08 15:12 ` Peter Zijlstra 2020-04-08 15:15 ` Matthew Wilcox 0 siblings, 1 reply; 36+ messages in thread From: Peter Zijlstra @ 2020-04-08 15:12 UTC (permalink / raw) To: Randy Dunlap Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Christoph Hellwig, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote: > Hi, > > On 4/8/20 4:59 AM, Christoph Hellwig wrote: > > diff --git a/mm/Kconfig b/mm/Kconfig > > index 36949a9425b8..614cc786b519 100644 > > --- a/mm/Kconfig > > +++ b/mm/Kconfig > > @@ -702,7 +702,7 @@ config ZSMALLOC > > > > config ZSMALLOC_PGTABLE_MAPPING > > bool "Use page table mapping to access object in zsmalloc" > > - depends on ZSMALLOC > > + depends on ZSMALLOC=y > > It's a bool so this shouldn't matter... not needed. My mm/Kconfig has: config ZSMALLOC tristate "Memory allocator for compressed pages" depends on MMU which I think means it can be modular, no? _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc 2020-04-08 15:12 ` Peter Zijlstra @ 2020-04-08 15:15 ` Matthew Wilcox 2020-04-08 15:36 ` Randy Dunlap [not found] ` <20200408153602.GA28081@lst.de> 0 siblings, 2 replies; 36+ messages in thread From: Matthew Wilcox @ 2020-04-08 15:15 UTC (permalink / raw) To: Peter Zijlstra Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Christoph Hellwig, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, Randy Dunlap, linux-kernel, Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On Wed, Apr 08, 2020 at 05:12:03PM +0200, Peter Zijlstra wrote: > On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote: > > Hi, > > > > On 4/8/20 4:59 AM, Christoph Hellwig wrote: > > > diff --git a/mm/Kconfig b/mm/Kconfig > > > index 36949a9425b8..614cc786b519 100644 > > > --- a/mm/Kconfig > > > +++ b/mm/Kconfig > > > @@ -702,7 +702,7 @@ config ZSMALLOC > > > > > > config ZSMALLOC_PGTABLE_MAPPING > > > bool "Use page table mapping to access object in zsmalloc" > > > - depends on ZSMALLOC > > > + depends on ZSMALLOC=y > > > > It's a bool so this shouldn't matter... not needed. > > My mm/Kconfig has: > > config ZSMALLOC > tristate "Memory allocator for compressed pages" > depends on MMU > > which I think means it can be modular, no? Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become 'n' instead of 'y'. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc 2020-04-08 15:15 ` Matthew Wilcox @ 2020-04-08 15:36 ` Randy Dunlap [not found] ` <20200408153602.GA28081@lst.de> 1 sibling, 0 replies; 36+ messages in thread From: Randy Dunlap @ 2020-04-08 15:36 UTC (permalink / raw) To: Matthew Wilcox, Peter Zijlstra Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Christoph Hellwig, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On 4/8/20 8:15 AM, Matthew Wilcox wrote: > On Wed, Apr 08, 2020 at 05:12:03PM +0200, Peter Zijlstra wrote: >> On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote: >>> Hi, >>> >>> On 4/8/20 4:59 AM, Christoph Hellwig wrote: >>>> diff --git a/mm/Kconfig b/mm/Kconfig >>>> index 36949a9425b8..614cc786b519 100644 >>>> --- a/mm/Kconfig >>>> +++ b/mm/Kconfig >>>> @@ -702,7 +702,7 @@ config ZSMALLOC >>>> >>>> config ZSMALLOC_PGTABLE_MAPPING >>>> bool "Use page table mapping to access object in zsmalloc" >>>> - depends on ZSMALLOC >>>> + depends on ZSMALLOC=y >>> >>> It's a bool so this shouldn't matter... not needed. >> >> My mm/Kconfig has: >> >> config ZSMALLOC >> tristate "Memory allocator for compressed pages" >> depends on MMU >> >> which I think means it can be modular, no? ack. I misread it. > Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch > is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become > 'n' instead of 'y'. sigh, I wish that I had meant that. :) thanks. -- ~Randy _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <20200408153602.GA28081@lst.de>]
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc [not found] ` <20200408153602.GA28081@lst.de> @ 2020-04-08 15:37 ` Randy Dunlap 0 siblings, 0 replies; 36+ messages in thread From: Randy Dunlap @ 2020-04-08 15:37 UTC (permalink / raw) To: Christoph Hellwig, Matthew Wilcox Cc: linux-hyperv, Peter Zijlstra, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, David Airlie, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On 4/8/20 8:36 AM, Christoph Hellwig wrote: > On Wed, Apr 08, 2020 at 08:15:19AM -0700, Matthew Wilcox wrote: >>>>> config ZSMALLOC_PGTABLE_MAPPING >>>>> bool "Use page table mapping to access object in zsmalloc" >>>>> - depends on ZSMALLOC >>>>> + depends on ZSMALLOC=y >>>> >>>> It's a bool so this shouldn't matter... not needed. >>> >>> My mm/Kconfig has: >>> >>> config ZSMALLOC >>> tristate "Memory allocator for compressed pages" >>> depends on MMU >>> >>> which I think means it can be modular, no? >> >> Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch >> is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become >> 'n' instead of 'y'. > > In Linus' tree you can select PGTABLE_MAPPING=y with ZSMALLOC=m, > and that fits my understanding of the kbuild language. With this > patch I can't anymore. > Makes sense. thanks. -- ~Randy _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc [not found] ` <20200408115926.1467567-11-hch@lst.de> 2020-04-08 15:01 ` [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc Randy Dunlap @ 2020-04-09 16:08 ` Minchan Kim 2020-04-09 16:50 ` Peter Zijlstra 1 sibling, 1 reply; 36+ messages in thread From: Minchan Kim @ 2020-04-09 16:08 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, sergey.senozhatsky, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On Wed, Apr 08, 2020 at 01:59:08PM +0200, Christoph Hellwig wrote: > This allows to unexport map_vm_area and unmap_kernel_range, which are > rather deep internal and should not be available to modules. Even though I don't know how many usecase we have using zsmalloc as module(I heard only once by dumb reason), it could affect existing users. Thus, please include concrete explanation in the patch to justify when the complain occurs. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > mm/Kconfig | 2 +- > mm/vmalloc.c | 2 -- > 2 files changed, 1 insertion(+), 3 deletions(-) > > diff --git a/mm/Kconfig b/mm/Kconfig > index 36949a9425b8..614cc786b519 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -702,7 +702,7 @@ config ZSMALLOC > > config ZSMALLOC_PGTABLE_MAPPING > bool "Use page table mapping to access object in zsmalloc" > - depends on ZSMALLOC > + depends on ZSMALLOC=y > help > By default, zsmalloc uses a copy-based object mapping method to > access allocations that span two pages. However, if a particular > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 3375f9508ef6..9183fc0d365a 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2046,7 +2046,6 @@ void unmap_kernel_range(unsigned long addr, unsigned long size) > vunmap_page_range(addr, end); > flush_tlb_kernel_range(addr, end); > } > -EXPORT_SYMBOL_GPL(unmap_kernel_range); > > int map_vm_area(struct vm_struct *area, pgprot_t prot, struct page **pages) > { > @@ -2058,7 +2057,6 @@ int map_vm_area(struct vm_struct *area, pgprot_t prot, struct page **pages) > > return err > 0 ? 0 : err; > } > -EXPORT_SYMBOL_GPL(map_vm_area); > > static inline void setup_vmalloc_vm_locked(struct vm_struct *vm, > struct vmap_area *va, unsigned long flags, const void *caller) > -- > 2.25.1 > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc 2020-04-09 16:08 ` Minchan Kim @ 2020-04-09 16:50 ` Peter Zijlstra 2020-04-09 17:08 ` Minchan Kim 0 siblings, 1 reply; 36+ messages in thread From: Peter Zijlstra @ 2020-04-09 16:50 UTC (permalink / raw) To: Minchan Kim Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Christoph Hellwig, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, sergey.senozhatsky, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On Thu, Apr 09, 2020 at 09:08:26AM -0700, Minchan Kim wrote: > On Wed, Apr 08, 2020 at 01:59:08PM +0200, Christoph Hellwig wrote: > > This allows to unexport map_vm_area and unmap_kernel_range, which are > > rather deep internal and should not be available to modules. > > Even though I don't know how many usecase we have using zsmalloc as > module(I heard only once by dumb reason), it could affect existing > users. Thus, please include concrete explanation in the patch to > justify when the complain occurs. The justification is 'we can unexport functions that have no sane reason of being exported in the first place'. The Changelog pretty much says that. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc 2020-04-09 16:50 ` Peter Zijlstra @ 2020-04-09 17:08 ` Minchan Kim 2020-04-10 2:38 ` Sergey Senozhatsky 0 siblings, 1 reply; 36+ messages in thread From: Minchan Kim @ 2020-04-09 17:08 UTC (permalink / raw) To: Peter Zijlstra Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Christoph Hellwig, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, sergey.senozhatsky, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On Thu, Apr 09, 2020 at 06:50:30PM +0200, Peter Zijlstra wrote: > On Thu, Apr 09, 2020 at 09:08:26AM -0700, Minchan Kim wrote: > > On Wed, Apr 08, 2020 at 01:59:08PM +0200, Christoph Hellwig wrote: > > > This allows to unexport map_vm_area and unmap_kernel_range, which are > > > rather deep internal and should not be available to modules. > > > > Even though I don't know how many usecase we have using zsmalloc as > > module(I heard only once by dumb reason), it could affect existing > > users. Thus, please include concrete explanation in the patch to > > justify when the complain occurs. > > The justification is 'we can unexport functions that have no sane reason > of being exported in the first place'. > > The Changelog pretty much says that. Okay, I hope there is no affected user since this patch. If there are someone, they need to provide sane reason why they want to have zsmalloc as module. Acked-by: Minchan Kim <minchan@kernel.org> _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc 2020-04-09 17:08 ` Minchan Kim @ 2020-04-10 2:38 ` Sergey Senozhatsky 2020-04-10 23:11 ` Minchan Kim 0 siblings, 1 reply; 36+ messages in thread From: Sergey Senozhatsky @ 2020-04-10 2:38 UTC (permalink / raw) To: Minchan Kim Cc: linux-hyperv, Peter Zijlstra, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Christoph Hellwig, David Airlie, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, sergey.senozhatsky, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On (20/04/09 10:08), Minchan Kim wrote: > > > Even though I don't know how many usecase we have using zsmalloc as > > > module(I heard only once by dumb reason), it could affect existing > > > users. Thus, please include concrete explanation in the patch to > > > justify when the complain occurs. > > > > The justification is 'we can unexport functions that have no sane reason > > of being exported in the first place'. > > > > The Changelog pretty much says that. > > Okay, I hope there is no affected user since this patch. > If there are someone, they need to provide sane reason why they want > to have zsmalloc as module. I'm one of those who use zsmalloc as a module - mainly because I use zram as a compressing general purpose block device, not as a swap device. I create zram0, mkfs, mount, checkout and compile code, once done - umount, rmmod. This reduces the number of writes to SSD. Some people use tmpfs, but zram device(-s) can be much larger in size. That's a niche use case and I'm not against the patch. -ss _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc 2020-04-10 2:38 ` Sergey Senozhatsky @ 2020-04-10 23:11 ` Minchan Kim [not found] ` <20200411072052.GA31242@lst.de> 0 siblings, 1 reply; 36+ messages in thread From: Minchan Kim @ 2020-04-10 23:11 UTC (permalink / raw) To: Sergey Senozhatsky Cc: linux-hyperv, Peter Zijlstra, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Christoph Hellwig, David Airlie, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev Hi Sergey, On Fri, Apr 10, 2020 at 11:38:45AM +0900, Sergey Senozhatsky wrote: > On (20/04/09 10:08), Minchan Kim wrote: > > > > Even though I don't know how many usecase we have using zsmalloc as > > > > module(I heard only once by dumb reason), it could affect existing > > > > users. Thus, please include concrete explanation in the patch to > > > > justify when the complain occurs. > > > > > > The justification is 'we can unexport functions that have no sane reason > > > of being exported in the first place'. > > > > > > The Changelog pretty much says that. > > > > Okay, I hope there is no affected user since this patch. > > If there are someone, they need to provide sane reason why they want > > to have zsmalloc as module. > > I'm one of those who use zsmalloc as a module - mainly because I use zram > as a compressing general purpose block device, not as a swap device. > I create zram0, mkfs, mount, checkout and compile code, once done - > umount, rmmod. This reduces the number of writes to SSD. Some people use > tmpfs, but zram device(-s) can be much larger in size. That's a niche use > case and I'm not against the patch. It doesn't mean we couldn't use zsmalloc as module any longer. It means we couldn't use zsmalloc as module with pgtable mapping whcih was little bit faster on microbenchmark in some architecutre(However, I usually temped to remove it since it had several problems). However, we could still use zsmalloc as module as copy way instead of pgtable mapping. Thus, if someone really want to rollback the feature, they should provide reasonable reason why it doesn't work for them. "A little fast" wouldn't be enough to exports deep internal to the module. Thanks. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <20200411072052.GA31242@lst.de>]
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc [not found] ` <20200411072052.GA31242@lst.de> @ 2020-04-16 20:37 ` Minchan Kim 0 siblings, 0 replies; 36+ messages in thread From: Minchan Kim @ 2020-04-16 20:37 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, Sergey Senozhatsky, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev Hi Christoph, Sorry for the late. On Sat, Apr 11, 2020 at 09:20:52AM +0200, Christoph Hellwig wrote: > Hi Minchan, > > On Fri, Apr 10, 2020 at 04:11:36PM -0700, Minchan Kim wrote: > > It doesn't mean we couldn't use zsmalloc as module any longer. It means > > we couldn't use zsmalloc as module with pgtable mapping whcih was little > > bit faster on microbenchmark in some architecutre(However, I usually temped > > to remove it since it had several problems). However, we could still use > > zsmalloc as module as copy way instead of pgtable mapping. Thus, if someone > > really want to rollback the feature, they should provide reasonable reason > > why it doesn't work for them. "A little fast" wouldn't be enough to exports > > deep internal to the module. > > do you have any data how much faster it is on arm (and does that include > arm64 as well)? Besides the exports which were my prime concern, https://github.com/sjenning/zsmapbench I need to recall the memory. IIRC, it was almost 30% faster at that time in ARM so was not trivial at that time. However, it was story from several years ago. > zsmalloc with pgtable mappings also is the only user of map_kernel_range > outside of vmalloc.c, if it really is another code base for tiny > improvements we could mark map_kernel_range or in fact remove it entirely > and open code it in the remaining callers. I alsh have temped to remove it. Let me have time to revist it in this chance. Thanks. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: decruft the vmalloc API [not found] <20200408115926.1467567-1-hch@lst.de> ` (10 preceding siblings ...) [not found] ` <20200408115926.1467567-11-hch@lst.de> @ 2020-04-08 16:03 ` Russell King - ARM Linux admin [not found] ` <20200408115926.1467567-26-hch@lst.de> ` (2 subsequent siblings) 14 siblings, 0 replies; 36+ messages in thread From: Russell King - ARM Linux admin @ 2020-04-08 16:03 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On Wed, Apr 08, 2020 at 01:58:58PM +0200, Christoph Hellwig wrote: > Hi all, > > Peter noticed that with some dumb luck you can toast the kernel address > space with exported vmalloc symbols. > > I used this as an opportunity to decruft the vmalloc.c API and make it > much more systematic. This also removes any chance to create vmalloc > mappings outside the designated areas or using executable permissions > from modules. Besides that it removes more than 300 lines of code. I haven't read all your patches yet. Have you tested it on 32-bit ARM, where the module area is located _below_ PAGE_OFFSET and outside of the vmalloc area? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <20200408115926.1467567-26-hch@lst.de>]
* Re: [PATCH 25/28] mm: remove vmalloc_user_node_flags [not found] ` <20200408115926.1467567-26-hch@lst.de> @ 2020-04-09 22:25 ` Andrii Nakryiko 2020-04-13 20:03 ` Johannes Weiner 0 siblings, 1 reply; 36+ messages in thread From: Andrii Nakryiko @ 2020-04-09 22:25 UTC (permalink / raw) To: Christoph Hellwig, Johannes Weiner Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, open list, Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev cc Johannes who suggested this API call originally On Wed, Apr 8, 2020 at 5:03 AM Christoph Hellwig <hch@lst.de> wrote: > > Open code it in __bpf_map_area_alloc, which is the only caller. Also > clean up __bpf_map_area_alloc to have a single vmalloc call with > slightly different flags instead of the current two different calls. > > For this to compile for the nommu case add a __vmalloc_node_range stub > to nommu.c. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > include/linux/vmalloc.h | 1 - > kernel/bpf/syscall.c | 23 +++++++++++++---------- > mm/nommu.c | 14 ++++++++------ > mm/vmalloc.c | 20 -------------------- > 4 files changed, 21 insertions(+), 37 deletions(-) > > diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h > index 108f49b47756..f90f2946aac2 100644 > --- a/include/linux/vmalloc.h > +++ b/include/linux/vmalloc.h > @@ -106,7 +106,6 @@ extern void *vzalloc(unsigned long size); > extern void *vmalloc_user(unsigned long size); > extern void *vmalloc_node(unsigned long size, int node); > extern void *vzalloc_node(unsigned long size, int node); > -extern void *vmalloc_user_node_flags(unsigned long size, int node, gfp_t flags); > extern void *vmalloc_exec(unsigned long size); > extern void *vmalloc_32(unsigned long size); > extern void *vmalloc_32_user(unsigned long size); > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c > index 48d98ea8fad6..249d9bd43321 100644 > --- a/kernel/bpf/syscall.c > +++ b/kernel/bpf/syscall.c > @@ -281,26 +281,29 @@ static void *__bpf_map_area_alloc(u64 size, int numa_node, bool mmapable) > * __GFP_RETRY_MAYFAIL to avoid such situations. > */ > > - const gfp_t flags = __GFP_NOWARN | __GFP_ZERO; > + const gfp_t gfp = __GFP_NOWARN | __GFP_ZERO; > + unsigned int flags = 0; > + unsigned long align = 1; > void *area; > > if (size >= SIZE_MAX) > return NULL; > > /* kmalloc()'ed memory can't be mmap()'ed */ > - if (!mmapable && size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) { > - area = kmalloc_node(size, GFP_USER | __GFP_NORETRY | flags, > + if (mmapable) { > + BUG_ON(!PAGE_ALIGNED(size)); > + align = SHMLBA; > + flags = VM_USERMAP; > + } else if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) { > + area = kmalloc_node(size, gfp | GFP_USER | __GFP_NORETRY, > numa_node); > if (area != NULL) > return area; > } > - if (mmapable) { > - BUG_ON(!PAGE_ALIGNED(size)); > - return vmalloc_user_node_flags(size, numa_node, GFP_KERNEL | > - __GFP_RETRY_MAYFAIL | flags); > - } > - return __vmalloc_node(size, 1, GFP_KERNEL | __GFP_RETRY_MAYFAIL | flags, > - numa_node, __builtin_return_address(0)); > + > + return __vmalloc_node_range(size, align, VMALLOC_START, VMALLOC_END, > + gfp | GFP_KERNEL | __GFP_RETRY_MAYFAIL, PAGE_KERNEL, > + flags, numa_node, __builtin_return_address(0)); > } > > void *bpf_map_area_alloc(u64 size, int numa_node) > diff --git a/mm/nommu.c b/mm/nommu.c > index 81a86cd85893..b42cd6003d7d 100644 > --- a/mm/nommu.c > +++ b/mm/nommu.c > @@ -150,6 +150,14 @@ void *__vmalloc(unsigned long size, gfp_t gfp_mask) > } > EXPORT_SYMBOL(__vmalloc); > > +void *__vmalloc_node_range(unsigned long size, unsigned long align, > + unsigned long start, unsigned long end, gfp_t gfp_mask, > + pgprot_t prot, unsigned long vm_flags, int node, > + const void *caller) > +{ > + return __vmalloc(size, flags); > +} > + > void *__vmalloc_node(unsigned long size, unsigned long align, gfp_t gfp_mask, > int node, const void *caller) > { > @@ -180,12 +188,6 @@ void *vmalloc_user(unsigned long size) > } > EXPORT_SYMBOL(vmalloc_user); > > -void *vmalloc_user_node_flags(unsigned long size, int node, gfp_t flags) > -{ > - return __vmalloc_user_flags(size, flags | __GFP_ZERO); > -} > -EXPORT_SYMBOL(vmalloc_user_node_flags); > - > struct page *vmalloc_to_page(const void *addr) > { > return virt_to_page(addr); > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 333fbe77255a..f6f2acdaf70c 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2658,26 +2658,6 @@ void *vzalloc_node(unsigned long size, int node) > } > EXPORT_SYMBOL(vzalloc_node); > > -/** > - * vmalloc_user_node_flags - allocate memory for userspace on a specific node > - * @size: allocation size > - * @node: numa node > - * @flags: flags for the page level allocator > - * > - * The resulting memory area is zeroed so it can be mapped to userspace > - * without leaking data. > - * > - * Return: pointer to the allocated memory or %NULL on error > - */ > -void *vmalloc_user_node_flags(unsigned long size, int node, gfp_t flags) > -{ > - return __vmalloc_node_range(size, SHMLBA, VMALLOC_START, VMALLOC_END, > - flags | __GFP_ZERO, PAGE_KERNEL, > - VM_USERMAP, node, > - __builtin_return_address(0)); > -} > -EXPORT_SYMBOL(vmalloc_user_node_flags); > - > /** > * vmalloc_exec - allocate virtually contiguous, executable memory > * @size: allocation size > -- > 2.25.1 > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 25/28] mm: remove vmalloc_user_node_flags 2020-04-09 22:25 ` [PATCH 25/28] mm: remove vmalloc_user_node_flags Andrii Nakryiko @ 2020-04-13 20:03 ` Johannes Weiner 0 siblings, 0 replies; 36+ messages in thread From: Johannes Weiner @ 2020-04-13 20:03 UTC (permalink / raw) To: Andrii Nakryiko Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Christoph Hellwig, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, open list, Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On Thu, Apr 09, 2020 at 03:25:03PM -0700, Andrii Nakryiko wrote: > cc Johannes who suggested this API call originally I forgot why we did it this way - probably just cruft begetting more cruft. Either way, Christoph's cleanup makes this look a lot better. > On Wed, Apr 8, 2020 at 5:03 AM Christoph Hellwig <hch@lst.de> wrote: > > > > Open code it in __bpf_map_area_alloc, which is the only caller. Also > > clean up __bpf_map_area_alloc to have a single vmalloc call with > > slightly different flags instead of the current two different calls. > > > > For this to compile for the nommu case add a __vmalloc_node_range stub > > to nommu.c. > > > > Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Johannes Weiner <hannes@cmpxchg.org> _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <20200408115926.1467567-21-hch@lst.de>]
* RE: [PATCH 20/28] mm: remove the pgprot argument to __vmalloc [not found] ` <20200408115926.1467567-21-hch@lst.de> @ 2020-04-10 20:39 ` Michael Kelley 0 siblings, 0 replies; 36+ messages in thread From: Michael Kelley @ 2020-04-10 20:39 UTC (permalink / raw) To: Christoph Hellwig, Andrew Morton, KY Srinivasan, Haiyang Zhang, Stephen Hemminger, Wei Liu, x86, David Airlie, Daniel Vetter, Laura Abbott, Sumit Semwal, Sakari Ailus, Minchan Kim, Nitin Gupta Cc: Christophe Leroy, linux-arch, linux-hyperv, linux-s390, Peter Zijlstra, linuxppc-dev, linux-kernel, dri-devel, linaro-mm-sig, linux-mm, iommu, bpf, Robin Murphy, linux-arm-kernel From: Christoph Hellwig <hch@lst.de> Sent: Wednesday, April 8, 2020 4:59 AM > > The pgprot argument to __vmalloc is always PROT_KERNEL now, so remove > it. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > arch/x86/hyperv/hv_init.c | 3 +-- > arch/x86/include/asm/kvm_host.h | 3 +-- > arch/x86/kvm/svm.c | 3 +-- > drivers/block/drbd/drbd_bitmap.c | 4 +--- > drivers/gpu/drm/etnaviv/etnaviv_dump.c | 4 ++-- > drivers/lightnvm/pblk-init.c | 5 ++--- > drivers/md/dm-bufio.c | 4 ++-- > drivers/mtd/ubi/io.c | 4 ++-- > drivers/scsi/sd_zbc.c | 3 +-- > fs/gfs2/dir.c | 9 ++++----- > fs/gfs2/quota.c | 2 +- > fs/nfs/blocklayout/extent_tree.c | 2 +- > fs/ntfs/malloc.h | 2 +- > fs/ubifs/debug.c | 2 +- > fs/ubifs/lprops.c | 2 +- > fs/ubifs/lpt_commit.c | 4 ++-- > fs/ubifs/orphan.c | 2 +- > fs/xfs/kmem.c | 2 +- > include/linux/vmalloc.h | 2 +- > kernel/bpf/core.c | 6 +++--- > kernel/groups.c | 2 +- > kernel/module.c | 3 +-- > mm/nommu.c | 15 +++++++-------- > mm/page_alloc.c | 2 +- > mm/percpu.c | 2 +- > mm/vmalloc.c | 4 ++-- > net/bridge/netfilter/ebtables.c | 6 ++---- > sound/core/memalloc.c | 2 +- > sound/core/pcm_memory.c | 2 +- > 29 files changed, 47 insertions(+), 59 deletions(-) > For Hyper-V changes, Reviewed-by: Michael Kelley <mikelley@microsoft.com> _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <20200408115926.1467567-2-hch@lst.de>]
* Re: [PATCH 01/28] x86/hyperv: use vmalloc_exec for the hypercall page [not found] ` <20200408115926.1467567-2-hch@lst.de> @ 2020-04-09 15:52 ` Wei Liu 2020-04-10 20:40 ` Michael Kelley 1 sibling, 0 replies; 36+ messages in thread From: Wei Liu @ 2020-04-09 15:52 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan, linux-arch, linux-s390, Wei Liu, Stephen Hemminger, x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Christophe Leroy, Robin Murphy, linux-kernel, Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev On Wed, Apr 08, 2020 at 01:58:59PM +0200, Christoph Hellwig wrote: > Use the designated helper for allocating executable kernel memory, and > remove the now unused PAGE_KERNEL_RX define. > > Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Wei Liu <wei.liu@kernel.org> _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: [PATCH 01/28] x86/hyperv: use vmalloc_exec for the hypercall page [not found] ` <20200408115926.1467567-2-hch@lst.de> 2020-04-09 15:52 ` [PATCH 01/28] x86/hyperv: use vmalloc_exec for the hypercall page Wei Liu @ 2020-04-10 20:40 ` Michael Kelley 1 sibling, 0 replies; 36+ messages in thread From: Michael Kelley @ 2020-04-10 20:40 UTC (permalink / raw) To: Christoph Hellwig, Andrew Morton, KY Srinivasan, Haiyang Zhang, Stephen Hemminger, Wei Liu, x86, David Airlie, Daniel Vetter, Laura Abbott, Sumit Semwal, Sakari Ailus, Minchan Kim, Nitin Gupta Cc: Christophe Leroy, linux-arch, linux-hyperv, linux-s390, Peter Zijlstra, linuxppc-dev, linux-kernel, dri-devel, linaro-mm-sig, linux-mm, iommu, bpf, Robin Murphy, linux-arm-kernel From: Christoph Hellwig <hch@lst.de> Sent: Wednesday, April 8, 2020 4:59 AM > > Use the designated helper for allocating executable kernel memory, and > remove the now unused PAGE_KERNEL_RX define. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > arch/x86/hyperv/hv_init.c | 2 +- > arch/x86/include/asm/pgtable_types.h | 2 -- > 2 files changed, 1 insertion(+), 3 deletions(-) > Reviewed-by: Michael Kelley <mikelley@microsoft.com> _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2020-04-16 20:37 UTC | newest] Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20200408115926.1467567-1-hch@lst.de> [not found] ` <20200408115926.1467567-27-hch@lst.de> 2020-04-08 12:18 ` [PATCH 26/28] arm64: use __vmalloc_node in arch_alloc_vmap_stack Mark Rutland [not found] ` <20200408115926.1467567-18-hch@lst.de> 2020-04-08 12:21 ` [PATCH 17/28] mm: remove the prot argument from vm_map_ram Peter Zijlstra 2020-04-09 0:39 ` Gao Xiang 2020-04-08 12:25 ` decruft the vmalloc API Peter Zijlstra [not found] ` <20200408115926.1467567-20-hch@lst.de> 2020-04-08 12:25 ` [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc Daniel Vetter 2020-04-09 8:54 ` Benjamin Herrenschmidt 2020-04-09 9:41 ` Daniel Vetter 2020-04-09 14:19 ` Alex Deucher 2020-04-09 14:57 ` Daniel Vetter 2020-04-09 22:56 ` Benjamin Herrenschmidt 2020-04-10 8:11 ` Daniel Vetter 2020-04-09 11:46 ` Gerhard Pircher [not found] ` <20200408115926.1467567-19-hch@lst.de> 2020-04-08 12:38 ` [PATCH 18/28] mm: enforce that vmap can't map pages executable Mark Rutland 2020-04-08 12:48 ` [PATCH 02/28] staging: android: ion: use vmap instead of vm_map_ram Hillf Danton [not found] ` <20200408115926.1467567-3-hch@lst.de> 2020-04-08 13:27 ` Greg KH [not found] ` <20200408115926.1467567-28-hch@lst.de> 2020-04-08 13:33 ` [PATCH 27/28] s390: use __vmalloc_node in alloc_vm_stack Christian Borntraeger [not found] ` <20200408115926.1467567-29-hch@lst.de> 2020-04-08 13:44 ` [PATCH 28/28] s390: use __vmalloc_node in stack_alloc Christian Borntraeger [not found] ` <20200408115926.1467567-10-hch@lst.de> 2020-04-08 15:00 ` [PATCH 09/28] mm: rename CONFIG_PGTABLE_MAPPING to CONFIG_ZSMALLOC_PGTABLE_MAPPING Randy Dunlap 2020-04-09 15:59 ` Minchan Kim [not found] ` <20200408115926.1467567-11-hch@lst.de> 2020-04-08 15:01 ` [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc Randy Dunlap 2020-04-08 15:12 ` Peter Zijlstra 2020-04-08 15:15 ` Matthew Wilcox 2020-04-08 15:36 ` Randy Dunlap [not found] ` <20200408153602.GA28081@lst.de> 2020-04-08 15:37 ` Randy Dunlap 2020-04-09 16:08 ` Minchan Kim 2020-04-09 16:50 ` Peter Zijlstra 2020-04-09 17:08 ` Minchan Kim 2020-04-10 2:38 ` Sergey Senozhatsky 2020-04-10 23:11 ` Minchan Kim [not found] ` <20200411072052.GA31242@lst.de> 2020-04-16 20:37 ` Minchan Kim 2020-04-08 16:03 ` decruft the vmalloc API Russell King - ARM Linux admin [not found] ` <20200408115926.1467567-26-hch@lst.de> 2020-04-09 22:25 ` [PATCH 25/28] mm: remove vmalloc_user_node_flags Andrii Nakryiko 2020-04-13 20:03 ` Johannes Weiner [not found] ` <20200408115926.1467567-21-hch@lst.de> 2020-04-10 20:39 ` [PATCH 20/28] mm: remove the pgprot argument to __vmalloc Michael Kelley [not found] ` <20200408115926.1467567-2-hch@lst.de> 2020-04-09 15:52 ` [PATCH 01/28] x86/hyperv: use vmalloc_exec for the hypercall page Wei Liu 2020-04-10 20:40 ` Michael Kelley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).