linux-kernel - Re: [PATCH 2/2] dmabuf/heaps: implement DMA_BUF_IOCTL_RW_FILE for system

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <fdd7a11b-140c-40bd-a1c1-334d69256b92@amd.com>
Date: Wed, 21 May 2025 09:35:34 +0200
From: Christian König <christian.koenig@....com>
To: wangtao <tao.wangtao@...or.com>, "T.J. Mercier" <tjmercier@...gle.com>
Cc: "sumit.semwal@...aro.org" <sumit.semwal@...aro.org>,
 "benjamin.gaignard@...labora.com" <benjamin.gaignard@...labora.com>,
 "Brian.Starkey@....com" <Brian.Starkey@....com>,
 "jstultz@...gle.com" <jstultz@...gle.com>,
 "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
 "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
 "linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "wangbintian(BintianWang)" <bintian.wang@...or.com>,
 yipengxiang <yipengxiang@...or.com>, liulu 00013167 <liulu.liu@...or.com>,
 hanfeng 00012985 <feng.han@...or.com>
Subject: Re: [PATCH 2/2] dmabuf/heaps: implement DMA_BUF_IOCTL_RW_FILE for
 system_heap

On 5/21/25 06:17, wangtao wrote:
>>> Reducing CPU overhead/power consumption is critical for mobile devices.
>>> We need simpler and more efficient dmabuf direct I/O support.
>>>
>>> As Christian evaluated sendfile performance based on your data, could
>>> you confirm whether the cache was cleared? If not, please share the
>>> post-cache-clearing test data. Thank you for your support.
>>
>> Yes sorry, I was out yesterday riding motorcycles. I did not clear the cache for
>> the buffered reads, I didn't realize you had. The IO plus the copy certainly
>> explains the difference.
>>
>> Your point about the unlikelihood of any of that data being in the cache also
>> makes sense.
> [wangtao] Thank you for testing and clarifying.
> 
>>
>> I'm not sure it changes anything about the ioctl approach though.
>> Another way to do this would be to move the (optional) support for direct IO
>> into the exporter via dma_buf_fops and dma_buf_ops. Then normal read()
>> syscalls would just work for buffers that support them.
>> I know that's more complicated, but at least it doesn't require inventing new
>> uapi to do it.
>>
> [wangtao] Thank you for the discussion. I fully support any method that enables
> dmabuf direct I/O.
> 
> I understand using sendfile/splice with regular files for dmabuf
> adds an extra CPU copy, preventing zero-copy. For example:
> sendfile path: [DISK] → DMA → [page cache] → CPU copy → [memory file].

Yeah, but why can't you work on improving that?

> The read() syscall can't pass regular file fd parameters, so I added
> an ioctl command.
> While copy_file_range() supports two fds (fd_in/fd_out), it blocks cross-fs use.
> Even without this restriction, file_out->f_op->copy_file_range
> only enables dmabuf direct reads from regular files, not writes.
> 
> Since dmabuf's direct I/O limitation comes from its unique
> attachment/map/fence model and lacks suitable syscalls, adding
> an ioctl seems necessary.

I absolutely don't see that. Both splice and sendfile can take two regular file descriptors.

That the underlying fops currently can't do that is not a valid argument for adding new uAPI. It just means that you need to work on improving those fops.

As long as nobody proves to me that the existing uAPI isn't sufficient for this use case I will systematically reject any approach to adding new one.

Regards,
Christian.

> When system exporters return a duplicated sg_table via map_dma_buf
> (used exclusively like a pages array), they should retain control
> over it.
> 
> I welcome all solutions to achieve dmabuf direct I/O! Your feedback
> is greatly appreciated.
>  
>> 1G from ext4 on 6.12.20 | read/sendfile (ms) w/ 3 > drop_caches
>> ------------------------|-------------------
>> udmabuf buffer read     | 1210
>> udmabuf direct read     | 671
>> udmabuf buffer sendfile | 1096
>> udmabuf direct sendfile | 2340
>>
>>
>>
>>>
>>>>>
>>>>>>> dmabuf buffer read     | 51         | 1068      | 1118
>>>>>>> dmabuf direct read     | 52         | 297       | 349
>>>>>>>
>>>>>>> udmabuf sendfile test steps:
>>>>>>> 1. Open data file(1024MB), get back_fd 2. Create memfd(32MB) #
>>>>>>> Loop steps 2-6 3. Allocate udmabuf with memfd 4. Call
>>>>>>> sendfile(memfd,
>>>>>>> back_fd) 5. Close memfd after sendfile 6. Close udmabuf 7.
>>>>>>> Close back_fd
>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Christian.
>>>>>>>
>>>>>>
>>>