On Wed, May 2, 2018 at 11:49 AM, Christian König
<ckoenig.leichtzumerken@xxxxxxxxx> wrote:
> Am 01.05.2018 um 15:24 schrieb Michel Dänzer:
>>
>> From: Michel Dänzer <michel.daenzer@xxxxxxx>
>>
>> The result was printing the warning only when we were explicitly asked
>> not to.
>>
>> Cc: stable@xxxxxxxxxxxxxxx
>> Fixes: 0176adb004065d6815a8e67946752df4cd947c5b "swiotlb: refactor
>> coherent buffer allocation"
>> Signed-off-by: Michel Dänzer <michel.daenzer@xxxxxxx>
>
>
> Good catch, looked at the code multiple times and haven't seen that myself
> :)
>
> Reviewed-by: Christian König <christian.koenig@xxxxxxx>.
Other dma-api backends like cma just shut up when __GFP_NOWARN is
passed. And afaiui Christoph Hellwig has plans to nuke the DMA_ATTR
stuff (or at least clean it up) - should we just remove
DMA_ATTR_NO_WARN and instead only look at __GFP_NOWARN?
For context the CMA patch:
commit ef4650144e76ae361fe4b8c9a0afcd53074cd520
Author: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxxxxxxx>
Date: Fri Oct 13 15:58:01 2017 -0700
mm/cma.c: take __GFP_NOWARN into account in cma_alloc()
Or maybe we should at least enforce that both or none are set, for
consistency for now?
Cheers, Daniel
>
> Christian.
>
>> ---
>> lib/swiotlb.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib/swiotlb.c b/lib/swiotlb.c
>> index c43ec2271469..e9ac21540628 100644
>> --- a/lib/swiotlb.c
>> +++ b/lib/swiotlb.c
>> @@ -750,7 +750,7 @@ swiotlb_alloc_buffer(struct device *dev, size_t size,
>> dma_addr_t *dma_handle,
>> swiotlb_tbl_unmap_single(dev, phys_addr, size, DMA_TO_DEVICE,
>> DMA_ATTR_SKIP_CPU_SYNC);
>> out_warn:
>> - if ((attrs & DMA_ATTR_NO_WARN) && printk_ratelimit()) {
>> + if (!(attrs & DMA_ATTR_NO_WARN) && printk_ratelimit()) {
>> dev_warn(dev,
>> "swiotlb: coherent allocation failed, size=%zu\n",
>> size);
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
