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

[Erfan Sharafzadeh <erfansh@meta.com>]

Replying to the Sashiko AI review of this patch. Three of the five
points are addressed in v2, which targets net-next:
https://lore.kernel.org/netdev/20261013210954.2170175-1-erfansh@meta.com/

1. Fixes: tag on an enhancement

Agreed. The static attach is correct under the dma-buf contract, and
the patch relies on 575157b1b5fc and 609fc8766d68, so it must not go to
stable. v2 drops the Fixes: tag and targets net-next.

2. "fall back as before"

Agreed, that was too broad. With an exporter that pins in a single
placement, a later attachment that cannot do P2P can fail to pin a
buffer that a P2P binding has already pinned in device memory, as with
pinned RDMA umem. v2 states this limit in the commit message.

3. Uninterruptible fence wait

Agreed. v2 waits interruptibly, as dma_buf_map_attachment() does for
static attachments.

4. dma_buf_pin() on every bind of a userspace-supplied dma-buf

Bindings were already pinned for their lifetime before this patch:
dma_buf_map_attachment() pins static attachments through
dma_buf_pin_on_map() and unpins them at unmap. The patch keeps the same
lifetime and only lets the exporter choose device memory. The amount is
bounded by what the user can allocate from the exporter in the first
place, and it is the same model as pinned RDMA umem. Whether BIND_TX
should require CAP_NET_ADMIN, as BIND_RX does, is a separate,
pre-existing question.

5. P2P bus addresses and no revocation

The binding is non-revocable, like ib_umem_dmabuf_attach_pinned_ops.
Devmem has no way to tear down a live binding today, since page_pool
and in-flight skbs hold references to it. Supporting revocable
bindings would be a separate change; v2 notes the limit in the commit
message.

pw-bot: cr