Re: [PATCH net-next v2] net: devmem: allow peer-to-peer dma-buf attach for bindings

[Stanislav Fomichev <sdf.kernel@gmail.com>]

On 10/13, Erfan Sharafzadeh wrote:
> net_devmem_bind_dmabuf() uses dma_buf_attach(), a static attachment
> with peer2peer false. Exporters must then keep the buffer reachable
> without P2P; amdgpu does so by placing it in GTT (system memory), so a
> device memory binding silently ends up in host memory.
> 
> Use dma_buf_dynamic_attach() with allow_peer2peer set, so an exporter
> that can do P2P to the device keeps the buffer in device memory.
> Dynamic attachments are not pinned on map, and devmem cannot handle the
> buffer moving, so:
> 
> - pin it with dma_buf_pin() before mapping, which keeps it in place for
>   the lifetime of the binding, as before;
> - wait for the exporter's kernel fences after mapping, interruptibly,
>   as the core does for static attachments.
> 
> This follows the pinned RDMA umem path, including its limits: the
> binding cannot be revoked by the exporter, and once a P2P binding has
> pinned a buffer in device memory, a later attachment to the same buffer
> that cannot do P2P may fail to pin it. Exporters that cannot do P2P to
> the device place the buffer as before. RX and TX bindings both go
> through this function.
> 
> Signed-off-by: Erfan Sharafzadeh <erfansh@meta.com>
> ---
> v2:
> - Target net-next and drop the Fixes: tag. This adds P2P placement
>   rather than fixing incorrect behaviour, and it relies on recent
>   dma-buf core changes, so it should not go to stable.
> - Wait for the exporter's fences interruptibly, as the core does.
> - Describe the revocation and mixed-attachment limits in the commit
>   message.
> 
> v1: https://lore.kernel.org/netdev/20261012170754.669462-1-erfansh@meta.com/

Acked-by: Stanislav Fomichev <sdf@fomichev.me>

We never with proper in-tree exporters (rather than "mock" udmabuf) so
here we are :-(