[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7a7a88e5-e620-914c-3265-1a6383ae1974@suse.cz>
Date: Mon, 16 Jul 2018 09:45:02 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Marek Szyprowski <m.szyprowski@...sung.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linuxppc-dev@...ts.ozlabs.org, iommu@...ts.linux-foundation.org
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Michal Nazarewicz <mina86@...a86.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Christoph Hellwig <hch@....de>, Michal Hocko <mhocko@...e.com>,
Russell King <linux@...linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
Paul Mackerras <paulus@...abs.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Chris Zankel <chris@...kel.net>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Joerg Roedel <joro@...tes.org>,
Sumit Semwal <sumit.semwal@...aro.org>,
Robin Murphy <robin.murphy@....com>,
Laura Abbott <labbott@...hat.com>,
linaro-mm-sig@...ts.linaro.org
Subject: Re: [PATCH 1/2] mm/cma: remove unsupported gfp_mask parameter from
cma_alloc()
On 07/09/2018 02:19 PM, Marek Szyprowski wrote:
> cma_alloc() function doesn't really support gfp flags other than
> __GFP_NOWARN, so convert gfp_mask parameter to boolean no_warn parameter.
>
> This will help to avoid giving false feeling that this function supports
> standard gfp flags and callers can pass __GFP_ZERO to get zeroed buffer,
> what has already been an issue: see commit dd65a941f6ba ("arm64:
> dma-mapping: clear buffers allocated with FORCE_CONTIGUOUS flag").
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@...sung.com>
Acked-by: Vlastimil Babka <vbabka@...e.cz>
Powered by blists - more mailing lists