[PATCH v2] ARM: DMA: Fix kzalloc flags in __dma_alloc

Commit 19e6e5e5392b ("ARM: 8547/1: dma-mapping: store buffer
information") allocates a structure meant for internal buffer management
with the GFP flags of the buffer itself. This can trigger the following
safeguard in the slab/slub allocator:

	if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
		pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
		BUG();
	}

Fix this by filtering the flags that make the slab allocator unhappy.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Cc: Rabin Vincent <redacted>
---
Changes since v1:
- Filter flags that may cause problem instead of forcing GFP_KERNEL
  (and risk sleeping in atomic context), as suggested by Rabin.

 arch/arm/mm/dma-mapping.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index deac58d5f1f7..c941e93048ad 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c

@@ -762,7 +762,8 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
 	if (!mask)
 		return NULL;
 
-	buf = kzalloc(sizeof(*buf), gfp);
+	buf = kzalloc(sizeof(*buf),
+		      gfp & ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM));
 	if (!buf)
 		return NULL;
 

-- 
2.7.3

On Fri, Mar 18, 2016 at 06:28:49PM +0900, Alexandre Courbot wrote:

Commit 19e6e5e5392b ("ARM: 8547/1: dma-mapping: store buffer
information") allocates a structure meant for internal buffer management
with the GFP flags of the buffer itself. This can trigger the following
safeguard in the slab/slub allocator:

	if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
		pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
		BUG();
	}

Fix this by filtering the flags that make the slab allocator unhappy.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Cc: Rabin Vincent <redacted>
---
Changes since v1:
- Filter flags that may cause problem instead of forcing GFP_KERNEL
  (and risk sleeping in atomic context), as suggested by Rabin.

Acked-by: Rabin Vincent <redacted>

Thanks.

On Fri, Mar 18, 2016 at 06:28:49PM +0900, Alexandre Courbot wrote:

Commit 19e6e5e5392b ("ARM: 8547/1: dma-mapping: store buffer
information") allocates a structure meant for internal buffer management
with the GFP flags of the buffer itself. This can trigger the following
safeguard in the slab/slub allocator:

	if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
		pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
		BUG();
	}

Fix this by filtering the flags that make the slab allocator unhappy.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Cc: Rabin Vincent <redacted>

Looks much better than the original.  Please send it to the patch system,
thanks.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

On Fri, Mar 18, 2016 at 7:58 PM, Russell King - ARM Linux
[off-list ref] wrote:

On Fri, Mar 18, 2016 at 06:28:49PM +0900, Alexandre Courbot wrote:

quoted

Commit 19e6e5e5392b ("ARM: 8547/1: dma-mapping: store buffer
information") allocates a structure meant for internal buffer management
with the GFP flags of the buffer itself. This can trigger the following
safeguard in the slab/slub allocator:

      if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
              pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
              BUG();
      }

Fix this by filtering the flags that make the slab allocator unhappy.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Cc: Rabin Vincent <redacted>

Looks much better than the original.  Please send it to the patch system,
thanks.

Just did that, thanks!