Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752142AbbBMFNv (ORCPT ); Fri, 13 Feb 2015 00:13:51 -0500 Received: from hqemgate15.nvidia.com ([216.228.121.64]:2899 "EHLO hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751588AbbBMFNn (ORCPT ); Fri, 13 Feb 2015 00:13:43 -0500 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Thu, 12 Feb 2015 21:13:14 -0800 Message-ID: <54DD87FB.6070802@nvidia.com> Date: Fri, 13 Feb 2015 14:13:31 +0900 From: Alexandre Courbot Organization: NVIDIA User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Will Deacon , Alexandre Courbot CC: Arnd Bergmann , Russell King , Marek Szyprowski , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH RESEND] ARM: DMA: Fix kzalloc flags in __iommu_alloc_buffer() References: <1423645301-709-1-git-send-email-acourbot@nvidia.com> <20150213033243.GC961@arm.com> In-Reply-To: <20150213033243.GC961@arm.com> X-NVConfidentiality: public X-Originating-IP: [10.19.57.128] X-ClientProxiedBy: DRBGMAIL101.nvidia.com (10.18.16.20) To HKMAIL103.nvidia.com (10.18.16.12) Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2258 Lines: 63 On 02/13/2015 12:32 PM, Will Deacon wrote: > 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. I have been trying to push this patch for so long that the line in question changed in the meantime. :) It is now if (unlikely(flags & GFP_SLAB_BUG_MASK)) { pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK); BUG(); } in cache_grow, line 2593 of mm/slab.c. > >> 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 >> Cc: Arnd Bergmann >> Cc: Marek Szyprowski >> Cc: Russell King >> Acked-by: Marek Szyprowski >> --- >> 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 Thanks! I will amend the commit message and resend. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/