linux-kernel - Re: [PATCH v4 0/4] Implement dmabuf direct I/O via copy_file

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: <924ac01f-b86b-4a03-b563-878fa7736712@amd.com>
Date: Tue, 3 Jun 2025 16:18:22 +0200
From: Christian König <christian.koenig@....com>
To: Christoph Hellwig <hch@...radead.org>
Cc: wangtao <tao.wangtao@...or.com>, sumit.semwal@...aro.org,
 kraxel@...hat.com, vivek.kasireddy@...el.com, viro@...iv.linux.org.uk,
 brauner@...nel.org, hughd@...gle.com, akpm@...ux-foundation.org,
 amir73il@...il.com, benjamin.gaignard@...labora.com, Brian.Starkey@....com,
 jstultz@...gle.com, tjmercier@...gle.com, jack@...e.cz,
 baolin.wang@...ux.alibaba.com, linux-media@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
 linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 linux-mm@...ck.org, bintian.wang@...or.com, yipengxiang@...or.com,
 liulu.liu@...or.com, feng.han@...or.com
Subject: Re: [PATCH v4 0/4] Implement dmabuf direct I/O via copy_file_range

On 6/3/25 15:19, Christoph Hellwig wrote:
> On Tue, Jun 03, 2025 at 03:14:20PM +0200, Christian König wrote:
>> On 6/3/25 15:00, Christoph Hellwig wrote:
>>> This is a really weird interface.  No one has yet to explain why dmabuf
>>> is so special that we can't support direct I/O to it when we can support
>>> it to otherwise exotic mappings like PCI P2P ones.
>>
>> With udmabuf you can do direct I/O, it's just inefficient to walk the
>> page tables for it when you already have an array of all the folios.
> 
> Does it matter compared to the I/O in this case?

It unfortunately does, see the numbers on patch 3 and 4.

I'm not very keen about it either, but I don't see much other way to do this.

> Either way there has been talk (in case of networking implementations)
> that use a dmabuf as a first class container for lower level I/O.
> I'd much rather do that than adding odd side interfaces.  I.e. have
> a version of splice that doesn't bother with the pipe, but instead
> just uses in-kernel direct I/O on one side and dmabuf-provided folios
> on the other.

That would work for me as well. But if splice or copy_file_range is used is not that important to me.

My question is rather if it's ok to call f_op->write_iter() and f_op->read_iter() with pages allocated by alloc_pages(), e.g. where drivers potentially ignore the page count and just re-use pages as they like?

Regards,
Christian.