linux-kernel - Re: [PATCH] dma-buf: add DMA_BUF_IOCTL_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 for Android: free password hash cracker in your pocket

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

Message-ID: <603470e5-3310-47c4-854e-d6fc36366699@vivo.com>
Date: Wed, 10 Apr 2024 15:09:42 +0800
From: Rong Qianfeng <11065417@...o.com>
To: Christian König <christian.koenig@....com>,
 Rong Qianfeng <rongqianfeng@...o.com>, Jianqun Xu <jay.xu@...k-chips.com>,
 sumit.semwal@...aro.org
Cc: pekka.paalanen@...labora.com, daniel.vetter@...ll.ch,
 jason@...kstrand.net, linux-media@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
 linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH] dma-buf: add DMA_BUF_IOCTL_SYNC_PARTIAL support


在 2024/4/9 23:34, Christian König 写道:
> Am 09.04.24 um 09:32 schrieb Rong Qianfeng:
>>
>> 在 2024/4/8 15:58, Christian König 写道:
>>> Am 07.04.24 um 09:50 schrieb Rong Qianfeng:
>>>> [SNIP]
>>>>> Am 13.11.21 um 07:22 schrieb Jianqun Xu:
>>>>>> Add DMA_BUF_IOCTL_SYNC_PARTIAL support for user to sync dma-buf with
>>>>>> offset and len.
>>>>>
>>>>> You have not given an use case for this so it is a bit hard to 
>>>>> review. And from the existing use cases I don't see why this 
>>>>> should be necessary.
>>>>>
>>>>> Even worse from the existing backend implementation I don't even 
>>>>> see how drivers should be able to fulfill this semantics.
>>>>>
>>>>> Please explain further,
>>>>> Christian.
>>>> Here is a practical case:
>>>> The user space can allocate a large chunk of dma-buf for 
>>>> self-management, used as a shared memory pool.
>>>> Small dma-buf can be allocated from this shared memory pool and 
>>>> released back to it after use, thus improving the speed of dma-buf 
>>>> allocation and release.
>>>> Additionally, custom functionalities such as memory statistics and 
>>>> boundary checking can be implemented in the user space.
>>>> Of course, the above-mentioned functionalities require the 
>>>> implementation of a partial cache sync interface.
>>>
>>> Well that is obvious, but where is the code doing that?
>>>
>>> You can't send out code without an actual user of it. That will 
>>> obviously be rejected.
>>>
>>> Regards,
>>> Christian.
>>
>> In fact, we have already used the user-level dma-buf memory pool in 
>> the camera shooting scenario on the phone.
>>
>> From the test results, The execution time of the photo shooting 
>> algorithm has been reduced from 3.8s to 3s.
>>
>> To be honest, I didn't understand your concern "...how drivers should 
>> be able to fulfill this semantics." Can you please help explain it in 
>> more detail?
>
> Well you don't give any upstream driver code which actually uses this 
> interface.
>
> If you want to suggest some changes to the core Linux kernel your 
> driver actually needs to be upstream.
>
> As long as that isn't the case this approach here is a completely no-go.

Ok, I get it now, thanks!

Regards,

Rong Qianfeng.

>
> Regards,
> Christian.
>
>>
>> Thanks,
>>
>> Rong Qianfeng.
>>
>>>
>>>>
>>>> Thanks
>>>> Rong Qianfeng.
>>>
>