On Wed, Jan 29, 2020 at 06:19:56PM +0100, Christian Borntraeger wrote: > On 29.01.20 18:09, Christoph Hellwig wrote: > > On Wed, Jan 29, 2020 at 06:07:14PM +0100, Christian Borntraeger wrote: > >>> DMA can be done to NORMAL memory as well. > >> > >> Exactly. > >> I think iucv uses GFP_DMA because z/VM needs those buffers to reside below 2GB (which is ZONA_DMA for s390). > > > > The normal way to allocate memory with addressing limits would be to > > use dma_alloc_coherent and friends. Any chance to switch iucv over to > > that? Or is there no device associated with it? > > There is not necessarily a device for that. It is a hypervisor interface (an > instruction that is interpreted by z/VM). We do have the netiucv driver that > creates a virtual nic, but there is also AF_IUCV which works without a device. > > But back to the original question: If we mark kmalloc caches as usercopy caches, > we should do the same for DMA kmalloc caches. As outlined by Christoph, this has > nothing to do with device DMA. Hm, looks like it's allocated from the low 16MB. Seems like poor naming! :) There seems to be a LOT of stuff using GFP_DMA, and it seems unlikely those are all expecting low addresses? Since this has only been a problem on s390, should just s390 gain the weakening of the usercopy restriction? Something like: diff --git a/mm/slab_common.c b/mm/slab_common.c index 1907cb2903c7..c5bbc141f20b 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -1303,7 +1303,9 @@ void __init create_kmalloc_caches(slab_flags_t flags) kmalloc_caches[KMALLOC_DMA][i] = create_kmalloc_cache( kmalloc_info[i].name[KMALLOC_DMA], kmalloc_info[i].size, - SLAB_CACHE_DMA | flags, 0, 0); + SLAB_CACHE_DMA | flags, 0, + IS_ENABLED(CONFIG_S390) ? + kmalloc_info[i].size : 0); } } #endif -- Kees Cook
