linux-kernel - Re: [RFC] Make use of non-dynamic dmabuf in RDMA

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]

Date:   Wed, 18 Aug 2021 10:00:40 +0200
From:   Christian König <christian.koenig@....com>
To:     Gal Pressman <galpress@...zon.com>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Doug Ledford <dledford@...hat.com>,
        Jason Gunthorpe <jgg@...pe.ca>
Cc:     linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, linux-rdma@...r.kernel.org,
        Oded Gabbay <ogabbay@...ana.ai>,
        Tomer Tayar <ttayar@...ana.ai>,
        Yossi Leybovich <sleybo@...zon.com>,
        Alexander Matushevsky <matua@...zon.com>,
        Leon Romanovsky <leonro@...dia.com>,
        Jianxin Xiong <jianxin.xiong@...el.com>
Subject: Re: [RFC] Make use of non-dynamic dmabuf in RDMA

Am 18.08.21 um 09:43 schrieb Gal Pressman:
> Hey all,
>
> Currently, the RDMA subsystem can only work with dynamic dmabuf
> attachments, which requires the RDMA device to support on-demand-paging
> (ODP) which is not common on most devices (only supported by mlx5).
>
> While the dynamic requirement makes sense for certain GPUs, some devices
> (such as habanalabs) have device memory that is always "pinned" and do
> not need/use the move_notify operation.
>
> The motivation of this RFC is to use habanalabs as the dmabuf exporter,
> and EFA as the importer to allow for peer2peer access through libibverbs.
>
> This draft patch changes the dmabuf driver to differentiate between
> static/dynamic attachments by looking at the move_notify op instead of
> the importer_ops struct, and allowing the peer2peer flag to be enabled
> in case of a static exporter.

Well NAK to the general approach, this can be solved much easier.

If you can't support dynamic moves while using the buffer then just pin 
all buffers during import/export.

This avoids the move notification and the framework/exporter can still 
correctly account for pinned buffers.

But please note that at least amdgpu never uses P2P support for pinned 
buffers since we want to avoid that unmoveable buffers clutter video 
memory and create conflicts with V4L and scanout.

If you don't have such concerns in habanalabs then you can implement the 
pinning there while keeping P2P still enabled.

Regards,
Christian.

>
> Thanks
>
> Signed-off-by: Gal Pressman <galpress@...zon.com>
> ---
>   drivers/dma-buf/dma-buf.c             | 5 +++--
>   drivers/infiniband/core/umem_dmabuf.c | 2 +-
>   include/linux/dma-buf.h               | 2 +-
>   3 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 511fe0d217a0..e3faad8f492c 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -727,7 +727,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
>   	if (WARN_ON(!dmabuf || !dev))
>   		return ERR_PTR(-EINVAL);
>   
> -	if (WARN_ON(importer_ops && !importer_ops->move_notify))
> +	if (WARN_ON(importer_ops && !importer_ops->move_notify &&
> +		    dma_buf_is_dynamic(attach->dmabuf)))
>   		return ERR_PTR(-EINVAL);
>   
>   	attach = kzalloc(sizeof(*attach), GFP_KERNEL);
> @@ -1048,7 +1049,7 @@ void dma_buf_move_notify(struct dma_buf *dmabuf)
>   	dma_resv_assert_held(dmabuf->resv);
>   
>   	list_for_each_entry(attach, &dmabuf->attachments, node)
> -		if (attach->importer_ops)
> +		if (attach->importer_ops && attach->importer_ops->move_notify)
>   			attach->importer_ops->move_notify(attach);
>   }
>   EXPORT_SYMBOL_GPL(dma_buf_move_notify);
> diff --git a/drivers/infiniband/core/umem_dmabuf.c b/drivers/infiniband/core/umem_dmabuf.c
> index c6e875619fac..c502ae828bd3 100644
> --- a/drivers/infiniband/core/umem_dmabuf.c
> +++ b/drivers/infiniband/core/umem_dmabuf.c
> @@ -118,7 +118,7 @@ struct ib_umem_dmabuf *ib_umem_dmabuf_get(struct ib_device *device,
>   	if (check_add_overflow(offset, (unsigned long)size, &end))
>   		return ret;
>   
> -	if (unlikely(!ops || !ops->move_notify))
> +	if (unlikely(!ops))
>   		return ret;
>   
>   	dmabuf = dma_buf_get(fd);
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index efdc56b9d95f..4b2e99012cb1 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -473,7 +473,7 @@ static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf)
>   static inline bool
>   dma_buf_attachment_is_dynamic(struct dma_buf_attachment *attach)
>   {
> -	return !!attach->importer_ops;
> +	return !!attach->importer_ops->move_notify;
>   }
>   
>   struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,