linux-kernel - Re: [RFC PATCH 1/3] RDMA/umem: Change for rdma devices has not dma device

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: <1c0356f5-19cf-e883-3d96-82a87d0cffcb@amd.com>
Date:   Wed, 8 Sep 2021 15:33:12 +0200
From:   Christian König <christian.koenig@....com>
To:     Jason Gunthorpe <jgg@...pe.ca>, Shunsuke Mie <mie@...l.co.jp>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Zhu Yanjun <zyjzyj2000@...il.com>,
        Alex Deucher <alexander.deucher@....com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Doug Ledford <dledford@...hat.com>,
        Jianxin Xiong <jianxin.xiong@...el.com>,
        Leon Romanovsky <leon@...nel.org>,
        linux-kernel@...r.kernel.org, linux-rdma@...r.kernel.org,
        Damian Hobson-Garcia <dhobsong@...l.co.jp>,
        Takanari Hayama <taki@...l.co.jp>,
        Tomohito Esaki <etom@...l.co.jp>
Subject: Re: [RFC PATCH 1/3] RDMA/umem: Change for rdma devices has not dma
 device

Am 08.09.21 um 13:18 schrieb Jason Gunthorpe:
> On Wed, Sep 08, 2021 at 05:41:39PM +0900, Shunsuke Mie wrote:
>> 2021年9月8日(水) 16:20 Christoph Hellwig <hch@...radead.org>:
>>> On Wed, Sep 08, 2021 at 04:01:14PM +0900, Shunsuke Mie wrote:
>>>> Thank you for your comment.
>>>>> On Wed, Sep 08, 2021 at 03:16:09PM +0900, Shunsuke Mie wrote:
>>>>>> To share memory space using dma-buf, a API of the dma-buf requires dma
>>>>>> device, but devices such as rxe do not have a dma device. For those case,
>>>>>> change to specify a device of struct ib instead of the dma device.
>>>>> So if dma-buf doesn't actually need a device to dma map why do we ever
>>>>> pass the dma_device here?  Something does not add up.
>>>> As described in the dma-buf api guide [1], the dma_device is used by dma-buf
>>>> exporter to know the device buffer constraints of importer.
>>>> [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.net%2FArticles%2F489703%2F&amp;data=04%7C01%7Cchristian.koenig%40amd.com%7C4d18470a94df4ed24c8108d972ba5591%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637666967356417448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ARwQyo%2BCjMohaNbyREofToHIj2bndL5L0HaU9cOrYq4%3D&amp;reserved=0
>>> Which means for rxe you'd also have to pass the one for the underlying
>>> net device.
>> I thought of that way too. In that case, the memory region is constrained by the
>> net device, but rxe driver copies data using CPU. To avoid the constraints, I
>> decided to use the ib device.
> Well, that is the whole problem.
>
> We can't mix the dmabuf stuff people are doing that doesn't fill in
> the CPU pages in the SGL with RXE - it is simply impossible as things
> currently are for RXE to acess this non-struct page memory.

Yeah, agree that doesn't make much sense.

When you want to access the data with the CPU then why do you want to 
use DMA-buf in the first place?

Please keep in mind that there is work ongoing to replace the sg table 
with an DMA address array and so make the underlying struct page 
inaccessible for importers.

Regards,
Christian.

>
> Jason