Skip to content
  • Nicolas Boichat's avatar
    mm: add support for kmem caches in DMA32 zone · 62d342d6
    Nicolas Boichat authored
    commit 6d6ea1e967a246f12cfe2f5fb743b70b2e608d4a upstream.
    
    Patch series "iommu/io-pgtable-arm-v7s: Use DMA32 zone for page tables",
    v6.
    
    This is a followup to the discussion in [1], [2].
    
    IOMMUs using ARMv7 short-descriptor format require page tables (level 1
    and 2) to be allocated within the first 4GB of RAM, even on 64-bit
    systems.
    
    For L1 tables that are bigger than a page, we can just use
    __get_free_pages with GFP_DMA32 (on arm64 systems only, arm would still
    use GFP_DMA).
    
    For L2 tables that only take 1KB, it would be a waste to allocate a full
    page, so we considered 3 approaches:
     1. This series, adding support for GFP_DMA32 slab caches.
     2. genalloc, which requires pre-allocating the maximum number of L2 page
        tables (4096, so 4MB of memory).
     3. page_frag, which is not very memory-efficient as it is unable to reuse
        freed fragments until the whole page is freed. [3]
    
    This series is the most memory-efficient approach.
    
    stable@ note:
      We confirmed that this is a regression, and IOMMU errors happen on 4.19
      and linux-next/master on MT8173 (elm, Acer Chromebook R13). The issue
      most likely starts from commit ad67f5a6 ("arm64: replace ZONE_DMA
      with ZONE_DMA32"), i.e. 4.15, and presumably breaks a number of Mediatek
      platforms (and maybe others?).
    
    [1] https://lists.linuxfoundation.org/pipermail/iommu/2018-November/030876.html
    [2] https://lists.linuxfoundation.org/pipermail/iommu/2018-December/031696.html
    [3] https://patchwork.codeaurora.org/patch/671639/
    
    This patch (of 3):
    
    IOMMUs using ARMv7 short-descriptor format require page tables to be
    allocated within the first 4GB of RAM, even on 64-bit systems.  On arm64,
    this is done by passing GFP_DMA32 flag to memory allocation functions.
    
    For IOMMU L2 tables that only take 1KB, it would be a waste to allocate
    a full page using get_free_pages, so we considered 3 approaches:
     1. This patch, adding support for GFP_DMA32 slab caches.
     2. genalloc, which requires pre-allocating the maximum number of L2
        page tables (4096, so 4MB of memory).
     3. page_frag, which is not very memory-efficient as it is unable
        to reuse freed fragments until the whole page is freed.
    
    This change makes it possible to create a custom cache in DMA32 zone using
    kmem_cache_create, then allocate memory using kmem_cache_alloc.
    
    We do not create a DMA32 kmalloc cache array, as there are currently no
    users of kmalloc(..., GFP_DMA32).  These calls will continue to trigger a
    warning, as we keep GFP_DMA32 in GFP_SLAB_BUG_MASK.
    
    This implies that calls to kmem_cache_*alloc on a SLAB_CACHE_DMA32
    kmem_cache must _not_ use GFP_DMA32 (it is anyway redundant and
    unnecessary).
    
    Link: http://lkml.kernel.org/r/20181210011504.122604-2-drinkcat@chromium.org
    
    
    Signed-off-by: default avatarNicolas Boichat <drinkcat@chromium.org>
    Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
    Acked-by: default avatarWill Deacon <will.deacon@arm.com>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Sasha Levin <Alexander.Levin@microsoft.com>
    Cc: Huaisheng Ye <yehs1@lenovo.com>
    Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
    Cc: Yong Wu <yong.wu@mediatek.com>
    Cc: Matthias Brugger <matthias.bgg@gmail.com>
    Cc: Tomasz Figa <tfiga@google.com>
    Cc: Yingjoe Chen <yingjoe.chen@mediatek.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Hsin-Yi Wang <hsinyi@chromium.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    62d342d6