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. 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
