Reply-To: christian.koenig@amd.com
Subject: Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v5
To: Christoph Hellwig <hch@infradead.org>
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org
References: <20180104132419.24536-1-christian.koenig@amd.com>
 <20180104132919.GA7213@infradead.org>
From: =?UTF-8?Q?Christian_K=c3=b6nig?= <ckoenig.leichtzumerken@gmail.com>
Message-ID: <7e470dfb-563f-2de4-7247-2949a528c6f6@gmail.com>
Date: Thu, 4 Jan 2018 14:49:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <20180104132919.GA7213@infradead.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org

Am 04.01.2018 um 14:29 schrieb Christoph Hellwig:
>> @@ -713,6 +713,7 @@ void *
>>   swiotlb_alloc_coherent(struct device *hwdev, size_t size,
>>   		       dma_addr_t *dma_handle, gfp_t flags)
>>   {
>> +	bool warn = !(flags & __GFP_NOWARN);
> This is still wrong.  __GFP_NOWARN has no meaning for DMA coherent
> allocations, and if a driver expects it to do anything it's doing it
> wrong.  This needs to check for DMA_ATTR_NO_WARN, and thus get the attrs
> passed.

I perfectly agree on that, but this is for stable kernel backports. 
Because of this I want to keep the footprint as low as possible.

When your patchset to clean that up lands for 4.16 I have no problem 
changing that.

But till then I think we should just work on suppress the warning for now.

Regards,
Christian.