在 2024/7/18 1:03, Christoph Hellwig 写道:
[Some people who received this message don't often get email from hch@xxxxxxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
On Wed, Jul 17, 2024 at 05:15:07PM +0200, Daniel Vetter wrote:
I'm talking about memfd, not dma-buf here. I think copy_file_range to
dma-buf is as architecturally unsound as allowing O_DIRECT on the dma-buf
mmap.
copy_file_range only work inside the same file system anyway, so
it is completely irrelevant here.
Yes, actually, if dma-buf want's to copy_file_range from a file, it need
change something in vfs_copy_file_range:
1. in generic_file_rw_checks, dma-buf file is not a normal file, but
inode_out check it. need bypass
2. file in and out need in the same file system which you point it. So,
need bypass it
3. if dma-buf above 2G, need bypass generic_write_check_limits's file
O_LARGEFILE check, it only allow copy range below 2G.
I feel that the above limitations indicate that copy_file_range is not
really suitable for copying between different file systems or
unconventional file types.(both shmemfs and other's)
Perhaps enabling dma-buf to support copy_file_range is not a good idea? :)
What should work just fine is using sendfile (or splice if you like it
complicated) to write TO the dma buf. That just iterates over the page
OK, I'll research it also.
cache on the source file and calls ->write_iter from the page cache
pages. Of course that requires that you actually implement
->write_iter, but given that dmabufs support mmaping there I can't
see why you should not be able to write to it.
Reading FROM the dma buf in that fashion should also work if you provide
a ->read_iter wire up ->splice_read to copy_splice_read so that it
doesn't require any page cache.
