From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RESEND] ARM: DMA: Fix kzalloc flags in __iommu_alloc_buffer()
Date: Fri, 13 Feb 2015 03:32:43 +0000 [thread overview]
Message-ID: <20150213033243.GC961@arm.com> (raw)
In-Reply-To: <1423645301-709-1-git-send-email-acourbot@nvidia.com>
On Wed, Feb 11, 2015 at 09:01:41AM +0000, Alexandre Courbot wrote:
> There doesn't seem to be any valid reason to allocate the pages array
> with the same flags as the buffer itself. Doing so can eventually lead
> to the following safeguard in mm/slab.c to be hit:
>
> BUG_ON(flags & GFP_SLAB_BUG_MASK);
nit: I can't actually spot this BUG_ON in the kernel.
> This happens when buffers are allocated with __GFP_DMA32 or
> __GFP_HIGHMEM.
>
> Fix this by allocating the pages array with GFP_KERNEL to follow what is
> done elsewhere in this file. Using GFP_KERNEL in __iommu_alloc_buffer()
> is safe because atomic allocations are handled by __iommu_alloc_atomic().
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/mm/dma-mapping.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 903dba0..170a116 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1106,7 +1106,7 @@ static struct page **__iommu_alloc_buffer(struct device *dev, size_t size,
> int i = 0;
>
> if (array_size <= PAGE_SIZE)
> - pages = kzalloc(array_size, gfp);
> + pages = kzalloc(array_size, GFP_KERNEL);
> else
> pages = vzalloc(array_size);
> if (!pages)
> --
> 2.3.0
Looks sensible to me:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Alexandre Courbot <gnurou@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Russell King <linux@arm.linux.org.uk>,
Marek Szyprowski <m.szyprowski@samsung.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Alexandre Courbot <acourbot@nvidia.com>
Subject: Re: [PATCH RESEND] ARM: DMA: Fix kzalloc flags in __iommu_alloc_buffer()
Date: Fri, 13 Feb 2015 03:32:43 +0000 [thread overview]
Message-ID: <20150213033243.GC961@arm.com> (raw)
In-Reply-To: <1423645301-709-1-git-send-email-acourbot@nvidia.com>
On Wed, Feb 11, 2015 at 09:01:41AM +0000, Alexandre Courbot wrote:
> There doesn't seem to be any valid reason to allocate the pages array
> with the same flags as the buffer itself. Doing so can eventually lead
> to the following safeguard in mm/slab.c to be hit:
>
> BUG_ON(flags & GFP_SLAB_BUG_MASK);
nit: I can't actually spot this BUG_ON in the kernel.
> This happens when buffers are allocated with __GFP_DMA32 or
> __GFP_HIGHMEM.
>
> Fix this by allocating the pages array with GFP_KERNEL to follow what is
> done elsewhere in this file. Using GFP_KERNEL in __iommu_alloc_buffer()
> is safe because atomic allocations are handled by __iommu_alloc_atomic().
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/mm/dma-mapping.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 903dba0..170a116 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1106,7 +1106,7 @@ static struct page **__iommu_alloc_buffer(struct device *dev, size_t size,
> int i = 0;
>
> if (array_size <= PAGE_SIZE)
> - pages = kzalloc(array_size, gfp);
> + pages = kzalloc(array_size, GFP_KERNEL);
> else
> pages = vzalloc(array_size);
> if (!pages)
> --
> 2.3.0
Looks sensible to me:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
next prev parent reply other threads:[~2015-02-13 3:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-11 9:01 [PATCH RESEND] ARM: DMA: Fix kzalloc flags in __iommu_alloc_buffer() Alexandre Courbot
2015-02-11 9:01 ` Alexandre Courbot
2015-02-13 3:32 ` Will Deacon [this message]
2015-02-13 3:32 ` Will Deacon
2015-02-13 5:13 ` Alexandre Courbot
2015-02-13 5:13 ` Alexandre Courbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150213033243.GC961@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.