All of lore.kernel.org
 help / color / mirror / Atom feed
* [patch 08/22] mm: add support for kmem caches in DMA32 zone
@ 2019-03-29  3:43 akpm
  2019-03-29 14:15 ` Christopher Lameter
       [not found] ` <20190330134526.281B6218AE@mail.kernel.org>
  0 siblings, 2 replies; 5+ messages in thread
From: akpm @ 2019-03-29  3:43 UTC (permalink / raw)
  To: akpm, Alexander.Levin, cl, drinkcat, hch, hsinyi, iamjoonsoo.kim,
	joro, matthias.bgg, mgorman, mhocko, mm-commits, penberg,
	rientjes, robin.murphy, rppt, stable, tfiga, torvalds, vbabka,
	will.deacon, willy, yehs1, yingjoe.chen, yong.wu

From: Nicolas Boichat <drinkcat@chromium.org>
Subject: mm: add support for kmem caches in DMA32 zone

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 <drinkcat@chromium.org>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Will 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: Andrew Morton <akpm@linux-foundation.org>
---

 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~mm-add-support-for-kmem-caches-in-dma32-zone
+++ a/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~mm-add-support-for-kmem-caches-in-dma32-zone
+++ a/mm/slab.c
@@ -2115,6 +2115,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_common.c~mm-add-support-for-kmem-caches-in-dma32-zone
+++ a/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/slab.h~mm-add-support-for-kmem-caches-in-dma32-zone
+++ a/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/slub.c~mm-add-support-for-kmem-caches-in-dma32-zone
+++ a/mm/slub.c
@@ -3589,6 +3589,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;
 
@@ -5679,6 +5682,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)
_

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [patch 08/22] mm: add support for kmem caches in DMA32 zone
  2019-03-29  3:43 [patch 08/22] mm: add support for kmem caches in DMA32 zone akpm
@ 2019-03-29 14:15 ` Christopher Lameter
  2019-03-29 15:04   ` Nicolas Boichat
       [not found] ` <20190330134526.281B6218AE@mail.kernel.org>
  1 sibling, 1 reply; 5+ messages in thread
From: Christopher Lameter @ 2019-03-29 14:15 UTC (permalink / raw)
  To: akpm
  Cc: Alexander.Levin, drinkcat, hch, hsinyi, iamjoonsoo.kim, joro,
	matthias.bgg, mgorman, mhocko, mm-commits, penberg, rientjes,
	robin.murphy, rppt, stable, tfiga, torvalds, vbabka, will.deacon,
	willy, yehs1, yingjoe.chen, yong.wu

On Thu, 28 Mar 2019, akpm@linux-foundation.org wrote:

> 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).

I hope you verified that this flag cannot be passed to kmem_cache_alloc()
and friends?


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [patch 08/22] mm: add support for kmem caches in DMA32 zone
  2019-03-29 14:15 ` Christopher Lameter
@ 2019-03-29 15:04   ` Nicolas Boichat
  0 siblings, 0 replies; 5+ messages in thread
From: Nicolas Boichat @ 2019-03-29 15:04 UTC (permalink / raw)
  To: Christopher Lameter
  Cc: Andrew Morton, Levin Alexander, hch, Hsin-Yi Wang, Joonsoo Kim,
	Joerg Roedel, Matthias Brugger, Mel Gorman, Michal Hocko,
	mm-commits, Pekka Enberg, David Rientjes, Robin Murphy,
	Mike Rapoport, stable, Tomasz Figa, torvalds, Vlastimil Babka,
	Will Deacon, Matthew Wilcox, Huaisheng Ye, Yingjoe Chen, Yong Wu

On Fri, Mar 29, 2019 at 7:15 AM Christopher Lameter <cl@linux.com> wrote:
>
> On Thu, 28 Mar 2019, akpm@linux-foundation.org wrote:
>
> > 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).
>
> I hope you verified that this flag cannot be passed to kmem_cache_alloc()
> and friends?

As highlighted in the commit message, just above the block that you
quote, we keep GFP_DMA32 in GFP_SLAB_BUG_MASK, so, yes,
kmem_cache_alloc with GFP_DMA32 will trigger a warning, nothing new
compared to previous behaviour:

    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.

(I very likely verified this 4 months ago when developing this series,
but now I can't remember for sure, I can test this again next week).

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [patch 08/22] mm: add support for kmem caches in DMA32 zone
       [not found] ` <20190330134526.281B6218AE@mail.kernel.org>
@ 2019-03-31 11:45   ` Nicolas Boichat
  2019-03-31 14:54     ` Greg Kroah-Hartman
  0 siblings, 1 reply; 5+ messages in thread
From: Nicolas Boichat @ 2019-03-31 11:45 UTC (permalink / raw)
  To: Sasha Levin
  Cc: Andrew Morton, Levin Alexander, Robin Murphy, Joerg Roedel,
	Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim,
	Michal Hocko, Mel Gorman, Huaisheng Ye, Mike Rapoport, Yong Wu,
	Matthias Brugger, Tomasz Figa, Yingjoe Chen, Christoph Hellwig,
	Matthew Wilcox, Hsin-Yi Wang, stable, Greg Kroah-Hartman

Hi Sasha,

On Sat, Mar 30, 2019 at 9:45 PM Sasha Levin <sashal@kernel.org> wrote:
>
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v5.0.5, v4.19.32, v4.14.109, v4.9.166, v4.4.177, v3.18.137.
>
> v5.0.5: Build OK!
> v4.19.32: Build OK!
> v4.14.109: Failed to apply! Possible dependencies:...
> v4.9.166: Failed to apply! Possible dependencies:...
> v4.4.177: Failed to apply! Possible dependencies:...
> v3.18.137: Failed to apply! Possible dependencies:...
>
> How should we proceed with this patch?

As highlighted in the stable notes for the series, the regression
happened in 4.15, sounds like I should have added some `# 4.15.x`
after the stable cc?

So we are ok with having the series applied to 4.19 and 5.0 only.

Thank you!

>
> --
> Thanks,
> Sasha

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [patch 08/22] mm: add support for kmem caches in DMA32 zone
  2019-03-31 11:45   ` Nicolas Boichat
@ 2019-03-31 14:54     ` Greg Kroah-Hartman
  0 siblings, 0 replies; 5+ messages in thread
From: Greg Kroah-Hartman @ 2019-03-31 14:54 UTC (permalink / raw)
  To: Nicolas Boichat
  Cc: Sasha Levin, Andrew Morton, Levin Alexander, Robin Murphy,
	Joerg Roedel, Christoph Lameter, Pekka Enberg, David Rientjes,
	Joonsoo Kim, Michal Hocko, Mel Gorman, Huaisheng Ye,
	Mike Rapoport, Yong Wu, Matthias Brugger, Tomasz Figa,
	Yingjoe Chen, Christoph Hellwig, Matthew Wilcox, Hsin-Yi Wang,
	stable

On Sun, Mar 31, 2019 at 07:45:05PM +0800, Nicolas Boichat wrote:
> Hi Sasha,
> 
> On Sat, Mar 30, 2019 at 9:45 PM Sasha Levin <sashal@kernel.org> wrote:
> >
> > Hi,
> >
> > [This is an automated email]
> >
> > This commit has been processed because it contains a -stable tag.
> > The stable tag indicates that it's relevant for the following trees: all
> >
> > The bot has tested the following trees: v5.0.5, v4.19.32, v4.14.109, v4.9.166, v4.4.177, v3.18.137.
> >
> > v5.0.5: Build OK!
> > v4.19.32: Build OK!
> > v4.14.109: Failed to apply! Possible dependencies:...
> > v4.9.166: Failed to apply! Possible dependencies:...
> > v4.4.177: Failed to apply! Possible dependencies:...
> > v3.18.137: Failed to apply! Possible dependencies:...
> >
> > How should we proceed with this patch?
> 
> As highlighted in the stable notes for the series, the regression
> happened in 4.15, sounds like I should have added some `# 4.15.x`
> after the stable cc?
> 
> So we are ok with having the series applied to 4.19 and 5.0 only.

That is fine, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-03-31 14:55 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-29  3:43 [patch 08/22] mm: add support for kmem caches in DMA32 zone akpm
2019-03-29 14:15 ` Christopher Lameter
2019-03-29 15:04   ` Nicolas Boichat
     [not found] ` <20190330134526.281B6218AE@mail.kernel.org>
2019-03-31 11:45   ` Nicolas Boichat
2019-03-31 14:54     ` Greg Kroah-Hartman

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.