linux-kernel - Re: [PATCH] dma-buf: heaps: remove duplicated cache sync

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <0b48df29-a20f-65f6-bc4c-6c0a7522ecd7@amd.com>
Date:   Tue, 31 Aug 2021 08:31:22 +0200
From:   Christian König <christian.koenig@....com>
To:     guangming.cao@...iatek.com
Cc:     Brian.Starkey@....com, benjamin.gaignard@...aro.org,
        dri-devel@...ts.freedesktop.org, john.stultz@...aro.org,
        labbott@...hat.com, linaro-mm-sig@...ts.linaro.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org, linux-mediatek@...ts.infradead.org,
        lmark@...eaurora.org, matthias.bgg@...il.com,
        sumit.semwal@...aro.org, wsd_upstream@...iatek.com
Subject: Re: [PATCH] dma-buf: heaps: remove duplicated cache sync

Am 31.08.21 um 05:44 schrieb guangming.cao@...iatek.com:
> From: Guangming Cao <Guangming.Cao@...iatek.com>
>
>> Am 30.08.21 um 12:01 schrieb guangming.cao@...iatek.com:
>>> From: Guangming Cao <Guangming.Cao@...iatek.com>
>>>
>>> Current flow, one dmabuf maybe call cache sync many times if
>>> it has beed mapped more than one time.
>> Well I'm not an expert on DMA heaps, but this will most likely not work
>> correctly.
>>
> All attachments of one dmabuf will add into a list, I think it means dmabuf
> supports map more than one time. Could you tell me more about it?

Yes, that's correct and all of those needs to be synced as far as I know.

See the dma_sync_sgtable_for_cpu() is intentionally for each SG table 
given out.

>>> Is there any case that attachments of one dmabuf will points to
>>> different memory? If not, seems do sync only one time is more better.
>> I think that this can happen, yes.
>>
>> Christian.
>>
> Seems it's a very special case on Android, if you don't mind, could you
> tell me more about it?

That might be the case, nevertheless this change here is illegal from 
the DMA API point of view as far as I can see.

Regards,
Christian.

>
>>> Signed-off-by: Guangming Cao <Guangming.Cao@...iatek.com>
>>> ---
>>>    drivers/dma-buf/heaps/system_heap.c | 14 ++++++++------
>>>    1 file changed, 8 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c
>>> index 23a7e74ef966..909ef652a8c8 100644
>>> --- a/drivers/dma-buf/heaps/system_heap.c
>>> +++ b/drivers/dma-buf/heaps/system_heap.c
>>> @@ -162,9 +162,10 @@ static int system_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
>>>    		invalidate_kernel_vmap_range(buffer->vaddr, buffer->len);
>>>    
>>>    	list_for_each_entry(a, &buffer->attachments, list) {
>>> -		if (!a->mapped)
>>> -			continue;
>>> -		dma_sync_sgtable_for_cpu(a->dev, a->table, direction);
>>> +		if (a->mapped) {
>>> +			dma_sync_sgtable_for_cpu(a->dev, a->table, direction);
>>> +			break;
>>> +		}
>>>    	}
>>>    	mutex_unlock(&buffer->lock);
>>>    
>>> @@ -183,9 +184,10 @@ static int system_heap_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>>>    		flush_kernel_vmap_range(buffer->vaddr, buffer->len);
>>>    
>>>    	list_for_each_entry(a, &buffer->attachments, list) {
>>> -		if (!a->mapped)
>>> -			continue;
>>> -		dma_sync_sgtable_for_device(a->dev, a->table, direction);
>>> +		if (!a->mapped) {
>>> +			dma_sync_sgtable_for_device(a->dev, a->table, direction);
>>> +			break;
>>> +		}
>>>    	}
>>>    	mutex_unlock(&buffer->lock);
>>>