Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp522035yba; Mon, 1 Apr 2019 11:00:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqwetUPgtAj599g2pPp/vUUIzIa2kkW5zA6FldNrF3eg9+wrGjIND8BFpAB+fVrLlz6ZRryd X-Received: by 2002:a62:ab13:: with SMTP id p19mr62982304pff.131.1554141630381; Mon, 01 Apr 2019 11:00:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554141630; cv=none; d=google.com; s=arc-20160816; b=fkiqqmsz6zo6RNVP9F4ZZbaCkR5aeHaGODe1gk0O3LkLWxZutjH6ENOksCNx32vXWj Y7vXnle33xpAzJFCsywT0ZvhjzHjw3OT0o0pfkVEipGk7SIzeXBBqoq8RiKIdDDHTo4E lRh9WkEbBbcTQyW7tKjttdm8sJ3fA9GJuEJKp0+Po8eEF7PmizoGrqwdJhoSVjLiSWgK xIwZpCNgAOr1amktHcIlVv+PCHZCOrcTPH5Xycr3wAsfISiGz7SOJ3q74molrXMh4StO H3Rsp6l9NTJLt4OWQEz12zn5c9TQ7Ao0ttgox9RzMgYi0ajQJiQ8JPi2mZ49cnJ8FEB5 /NBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=2wQHlVpOKvh0dxKkPAepGUj+ynRARyKrd1pErOnpzmk=; b=Du9RDKZOvJauzYkFhmCPnjDWWf/xuTv/XBiOPaxXlI0JFuUCeUYOZPVGxT9PgyjLlS cXKMzM2K7F/mnihxzFvp9teyJrfqIhm8JUuFiS/dhHSLhdO9ndxJTSKa6aW9Oq9qHGm6 ujFcYWEu9fQ0qXMhwVKUZSv1j5/4kg0i/xdyuFo/IqimPsaqW5WMOKOyMi7dGEloabV3 IrRv+2Qn9kfGU/BJWuoqfN9BjiU7r1LusACte/M7BwD611eSvlZoJ+ATYYc0370MJH0k CBhuFhkSG+8rUhGrIZD8dsFkun0b/TReFJU3gbg08HHCUw2XOfHvlMa72ChVIKkVW+nW ZPSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=qyakZ2ad; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v79si9025243pgb.56.2019.04.01.11.00.14; Mon, 01 Apr 2019 11:00:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=qyakZ2ad; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731398AbfDARSm (ORCPT + 99 others); Mon, 1 Apr 2019 13:18:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:46042 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730959AbfDARSi (ORCPT ); Mon, 1 Apr 2019 13:18:38 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C99622171F; Mon, 1 Apr 2019 17:18:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554139117; bh=uQVtPtytSgfQ/BPTEqJ0cjyGGNb0l8qcXbmePt3Ustc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qyakZ2adBT6UgoCcWQfoHULW+HxHcqwe1SbytZuFpUhjzdVdncU6wxHl2gDa4jmFj bNkvX58YxeiHUh42qSRjQUCtIo2mUWQwzAuhjycmnNbukTJ6E7qHieL1tDf/Drytsy kjtHoadLegChuLK5qy2NwHIuNAdNycyq5Vm92AvQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicolas Boichat , Vlastimil Babka , Will Deacon , Robin Murphy , Joerg Roedel , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Michal Hocko , Mel Gorman , Sasha Levin , Huaisheng Ye , Mike Rapoport , Yong Wu , Matthias Brugger , Tomasz Figa , Yingjoe Chen , Christoph Hellwig , Matthew Wilcox , Hsin-Yi Wang , Andrew Morton , Linus Torvalds Subject: [PATCH 4.19 111/134] mm: add support for kmem caches in DMA32 zone Date: Mon, 1 Apr 2019 19:02:27 +0200 Message-Id: <20190401170054.591754683@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190401170044.243719205@linuxfoundation.org> References: <20190401170044.243719205@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.19-stable review patch. If anyone has any objections, please let me know. ------------------ From: Nicolas Boichat 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 ad67f5a6545f ("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: Nicolas Boichat Acked-by: Vlastimil Babka Acked-by: Will Deacon Cc: Robin Murphy Cc: Joerg Roedel Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: Michal Hocko Cc: Mel Gorman Cc: Sasha Levin Cc: Huaisheng Ye Cc: Mike Rapoport Cc: Yong Wu Cc: Matthias Brugger Cc: Tomasz Figa Cc: Yingjoe Chen Cc: Christoph Hellwig Cc: Matthew Wilcox Cc: Hsin-Yi Wang Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- include/linux/slab.h | 2 ++ mm/slab.c | 2 ++ mm/slab.h | 3 ++- mm/slab_common.c | 2 +- mm/slub.c | 5 +++++ 5 files changed, 12 insertions(+), 2 deletions(-) --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -32,6 +32,8 @@ #define SLAB_HWCACHE_ALIGN ((slab_flags_t __force)0x00002000U) /* Use GFP_DMA memory */ #define SLAB_CACHE_DMA ((slab_flags_t __force)0x00004000U) +/* Use GFP_DMA32 memory */ +#define SLAB_CACHE_DMA32 ((slab_flags_t __force)0x00008000U) /* DEBUG: Store the last owner for bug hunting */ #define SLAB_STORE_USER ((slab_flags_t __force)0x00010000U) /* Panic if kmem_cache_create() fails */ --- a/mm/slab.c +++ b/mm/slab.c @@ -2124,6 +2124,8 @@ done: cachep->allocflags = __GFP_COMP; if (flags & SLAB_CACHE_DMA) cachep->allocflags |= GFP_DMA; + if (flags & SLAB_CACHE_DMA32) + cachep->allocflags |= GFP_DMA32; if (flags & SLAB_RECLAIM_ACCOUNT) cachep->allocflags |= __GFP_RECLAIMABLE; cachep->size = size; --- a/mm/slab.h +++ b/mm/slab.h @@ -127,7 +127,8 @@ static inline slab_flags_t kmem_cache_fl /* Legal flag mask for kmem_cache_create(), for various configurations */ -#define SLAB_CORE_FLAGS (SLAB_HWCACHE_ALIGN | SLAB_CACHE_DMA | SLAB_PANIC | \ +#define SLAB_CORE_FLAGS (SLAB_HWCACHE_ALIGN | SLAB_CACHE_DMA | \ + SLAB_CACHE_DMA32 | SLAB_PANIC | \ SLAB_TYPESAFE_BY_RCU | SLAB_DEBUG_OBJECTS ) #if defined(CONFIG_DEBUG_SLAB) --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -53,7 +53,7 @@ static DECLARE_WORK(slab_caches_to_rcu_d SLAB_FAILSLAB | SLAB_KASAN) #define SLAB_MERGE_SAME (SLAB_RECLAIM_ACCOUNT | SLAB_CACHE_DMA | \ - SLAB_ACCOUNT) + SLAB_CACHE_DMA32 | SLAB_ACCOUNT) /* * Merge control. If this is set then no merging of slab caches will occur. --- a/mm/slub.c +++ b/mm/slub.c @@ -3539,6 +3539,9 @@ static int calculate_sizes(struct kmem_c if (s->flags & SLAB_CACHE_DMA) s->allocflags |= GFP_DMA; + if (s->flags & SLAB_CACHE_DMA32) + s->allocflags |= GFP_DMA32; + if (s->flags & SLAB_RECLAIM_ACCOUNT) s->allocflags |= __GFP_RECLAIMABLE; @@ -5633,6 +5636,8 @@ static char *create_unique_id(struct kme */ if (s->flags & SLAB_CACHE_DMA) *p++ = 'd'; + if (s->flags & SLAB_CACHE_DMA32) + *p++ = 'D'; if (s->flags & SLAB_RECLAIM_ACCOUNT) *p++ = 'a'; if (s->flags & SLAB_CONSISTENCY_CHECKS)