linux-kernel - Re: [PATCH 1/2] dma-buf: heaps: DMA_HEAP_IOCTL_ALLOC_READ

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: <7140a145-7dd5-43b0-8b2a-0fd12bb9e62d@vivo.com>
Date: Thu, 18 Jul 2024 09:51:39 +0800
From: Huan Yang <link@...o.com>
To: Christoph Hellwig <hch@...radead.org>,
 Christian König <christian.koenig@....com>,
 Sumit Semwal <sumit.semwal@...aro.org>,
 Benjamin Gaignard <benjamin.gaignard@...labora.com>,
 Brian Starkey <Brian.Starkey@....com>, John Stultz <jstultz@...gle.com>,
 "T.J. Mercier" <tjmercier@...gle.com>, linux-media@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
 linux-kernel@...r.kernel.org, opensource.kernel@...o.com
Subject: Re: [PATCH 1/2] dma-buf: heaps: DMA_HEAP_IOCTL_ALLOC_READ_FILE
 framework

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