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. - The documentation error in patch 2 is real. - 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. - 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. Thanks, Alex [1]https://sashiko.dev/#/patchset/[email protected] [2]https://lore.kernel.org/linux-rdma/[email protected]
