linux-kernel - Re: [PATCH 0/2] Support direct I/O read and write for memory allocated by dmabuf

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: <0393cf47-3fa2-4e32-8b3d-d5d5bdece298@amd.com>
Date: Wed, 10 Jul 2024 16:48:07 +0200
From: Christian König <christian.koenig@....com>
To: Lei Liu <liulei.rjpt@...o.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>,
 Andrew Morton <akpm@...ux-foundation.org>,
 David Hildenbrand <david@...hat.com>, Matthew Wilcox <willy@...radead.org>,
 Muhammad Usama Anjum <usama.anjum@...labora.com>,
 Andrei Vagin <avagin@...gle.com>, Ryan Roberts <ryan.roberts@....com>,
 Kefeng Wang <wangkefeng.wang@...wei.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, Daniel Vetter <daniel@...ll.ch>,
 "Vetter, Daniel" <daniel.vetter@...el.com>
Cc: opensource.kernel@...o.com
Subject: Re: [PATCH 0/2] Support direct I/O read and write for memory
 allocated by dmabuf

Am 10.07.24 um 16:35 schrieb Lei Liu:
>
> 在 2024/7/10 22:14, Christian König 写道:
>> Am 10.07.24 um 15:57 schrieb Lei Liu:
>>> Use vm_insert_page to establish a mapping for the memory allocated
>>> by dmabuf, thus supporting direct I/O read and write; and fix the
>>> issue of incorrect memory statistics after mapping dmabuf memory.
>>
>> Well big NAK to that! Direct I/O is intentionally disabled on DMA-bufs.
>
> Hello! Could you explain why direct_io is disabled on DMABUF? Is there 
> any historical reason for this?

It's basically one of the most fundamental design decision of DMA-Buf. 
The attachment/map/fence model DMA-buf uses is not really compatible 
with direct I/O on the underlying pages.

>>
>> We already discussed enforcing that in the DMA-buf framework and this 
>> patch probably means that we should really do that.
>>
>> Regards,
>> Christian.
>
> Thank you for your response. With the application of AI large model 
> edgeification, we urgently need support for direct_io on DMABUF to 
> read some very large files. Do you have any new solutions or plans for 
> this?

We have seen similar projects over the years and all of those turned out 
to be complete shipwrecks.

There is currently a patch set under discussion to give the network 
subsystem DMA-buf support. If you are interest in network direct I/O 
that could help.

Additional to that a lot of GPU drivers support userptr usages, e.g. to 
import malloced memory into the GPU driver. You can then also do direct 
I/O on that malloced memory and the kernel will enforce correct handling 
with the GPU driver through MMU notifiers.

But as far as I know a general DMA-buf based solution isn't possible.

Regards,
Christian.

>
> Regards,
> Lei Liu.
>
>>
>>>
>>> Lei Liu (2):
>>>    mm: dmabuf_direct_io: Support direct_io for memory allocated by 
>>> dmabuf
>>>    mm: dmabuf_direct_io: Fix memory statistics error for dmabuf 
>>> allocated
>>>      memory with direct_io support
>>>
>>>   drivers/dma-buf/heaps/system_heap.c |  5 +++--
>>>   fs/proc/task_mmu.c                  |  8 +++++++-
>>>   include/linux/mm.h                  |  1 +
>>>   mm/memory.c                         | 15 ++++++++++-----
>>>   mm/rmap.c                           |  9 +++++----
>>>   5 files changed, 26 insertions(+), 12 deletions(-)
>>>
>>