On Fri, Jul 10, 2026 at 02:13:31PM -0700, Zhiping Zhang wrote: > On Thu, Jul 9, 2026 at 12:26 PM Alex Williamson <[email protected]> wrote: > > > > > > > On Thu, 2 Jul 2026 11:10:13 -0700 > > Zhiping Zhang <[email protected]> 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/[email protected]/ Thanks > > I plan to keep it as a standalone dependency. > > > Thanks, > > Alex > > > > [1]https://urldefense.com/v3/__https://sashiko.dev/*/patchset/[email protected]__;Iw!!Bt8RZUm9aw!5x8TPHfbpTXQJ872nmZaHsPIXH7HsL9ICbZR3G37yKkHgB-RukCDOy3XiLIOhfhP-yTczTyWQmud$ > > [2]https://lore.kernel.org/linux-rdma/[email protected] > > Thanks, > Zhiping
