Re: [RFC 2/2] Set steering-tag directly for PCIe P2P memory access

[Jason Gunthorpe <jgg@ziepe.ca>]

On Fri, Jan 23, 2026 at 05:13:19PM -0800, Zhiping Zhang wrote:
> On Tue, 13 Jan 2026 12:49:23 -0400, Jason Gunthorpe wrote:
> 
> > On Mon, Jan 12, 2026 at 11:43:13PM -0800, Zhiping Zhang wrote:
> > > Got it, thanks for pointing out the security concern! To address this, I
> > > propose that we still pass the TPH value when allocating the dmah, but we add
> > > a verification callback in the reg_mr_dmabuf flow to the dmabuf exporter. This
> > > callback will ensure that the TPH value is correctly linked to the exporting
> > > device’s MMIO, and only the exporter can authorize the TPH/tag association.
> 
> > That still sounds messy because we have to protect CPU memory.
> 
> > I think you should not use dmah possibly and make it so the dmabuf
> entirely supplies the TPH value.
> 
> > Jason
> 
> Thanks Jason.
> 
> We already have an end-to-end workflow around dmah (perftest → rdma-core → kernel)
> to carry the TPH hint, across multiple patch sets. References:
>   https://github.com/linux-rdma/perftest/commit/98bfb3679a1e71ec96df6a6d6c8124ac66ebce25
>   https://github.com/linux-rdma/rdma-core/pull/1623/commits
>   https://lore.kernel.org/all/cover.1752752567.git.leon@kernel.org/
> 
> Given that, I’d like to minimize churn and use the existing dmah-based flow, while
> addressing the CPU-memory protection concern you raised. Would you be open to
> reconsidering this approach?

You would need to initialize the dmah from the dmabuf and then lock it
to only be usable with that dmabuf. It doesn't avoid any dmabuf work,
it just makes the whole flow more convoluted.

Jason