[PATCH 1/2] dma-buf: heaps: DMA_HEAP_IOCTL_ALLOC_READ_FILE framework

[Huan Yang]

在 2024/7/18 1:03, Christoph Hellwig 写道:
> [Some people who received this message don't often get email from hch at infradead.org. 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.
>