Re: [PATCH v11 0/4] vfio/dma-buf: add TPH support for peer-to-peer access

[Leon Romanovsky <leon@kernel.org>]

On Fri, Jul 10, 2026 at 02:13:31PM -0700, Zhiping Zhang wrote:
> On Thu, Jul 9, 2026 at 12:26 PM Alex Williamson <alex@shazbot.org> wrote:
> >
> > >
> > On Thu, 2 Jul 2026 11:10:13 -0700
> > Zhiping Zhang <zhipingz@meta.com> wrote:
> >
> > > Changes since v10:
> > >   Patch 2 (dma-buf): Per Christian König, document that the ST/PH
> > >   returned by dma_buf_get_pci_tph() is only valid until the exporter
> > >   invalidates the current mapping and must be re-queried afterwards;
> > >   note added to the wrapper kernel-doc and referenced from the callback
> > >   kernel-doc. Also add dma_buf_get_pci_tph() and dma_buf_ops.get_pci_tph()
> > >   to the central dma-buf locking convention.
> > >
> > >   Patch 3 (vfio/pci): Per Alex Williamson, update the vfio_pci_dma_buf
> > >   comment to note that @revoked is additionally protected by memory_lock,
> > >   and describe the READ_ONCE() rationale in the commit log. No behavior
> > >   change.
> >
> > Sashiko has valid comments[1] across most of the series.
> >
> >  - Passing through 0b10 seems mis-categorized as High in patch 1, but
> >    is valid hardening if tph_req_type can ever hold an invalid value.
> >
> 
> agreed, not High and pre-existing: get_rp_completer_type() is from the
> original TPH
> support and untouched here. I can send the hardening change in a separate patch.
> 
> >  - The documentation error in patch 2 is real.
> >
> 
> will fix!
> 
> >  - Patch 4 ironically fails to re-validate according to the lifecycle
> >    requirements that patch 2 specifies.  This is a significant gap in
> >    the implementation proof for a real requester.
> >
> 
> Got it, I'll re-query ma_buf_get_pci_tph() there and reprogram the
> mkey's steering tag,
> so the lifecycle is honored.
> 
> >  - The broadened scope of the existing memory leak in patch 4 is
> >    already addressed in [2], ok.  Maybe should be folded into this
> >    series if mlx5 isn't going to pick it up separately.
> >
> 
>  [2] is already accepted and landing through the mlx5/RDMA tree.

It is not; the patch is intended for net and has still not been
accepted.

https://lore.kernel.org/linux-rdma/20260702222507.1234467-1-zhipingz@meta.com/

Thanks

> 
> I plan to keep it as a standalone dependency.
> 
> > Thanks,
> > Alex
> >
> > [1]https://urldefense.com/v3/__https://sashiko.dev/*/patchset/20260702181025.2694961-1-zhipingz@meta.com__;Iw!!Bt8RZUm9aw!5x8TPHfbpTXQJ872nmZaHsPIXH7HsL9ICbZR3G37yKkHgB-RukCDOy3XiLIOhfhP-yTczTyWQmud$
> > [2]https://lore.kernel.org/linux-rdma/20260612170406.3339093-1-zhipingz@meta.com
> 
> Thanks,
> Zhiping