From: sashiko-bot@kernel.org
To: "Zhiping Zhang" <zhipingz@meta.com>
Cc: linux-pci@vger.kernel.org, kvm@vger.kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v7 4/5] vfio/pci: implement get_tph and DMA_BUF_TPH feature
Date: Thu, 11 Jun 2026 20:25:55 +0000 [thread overview]
Message-ID: <20260611202555.B0FE31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260610193158.2614209-5-zhipingz@meta.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Unconditional validation of the flag-gated 'ph' parameter can lead to spurious -EINVAL errors, breaking the syscall trust boundary.
- [Medium] VFIO_DEVICE_FEATURE_PROBE falsely reports that VFIO_DEVICE_FEATURE_DMA_BUF_TPH is supported even if the hardware lacks TPH support.
--
commit d57637d667ca6dc95def77a0a5bd339d62d4f506
Author: Zhiping Zhang <zhipingz@meta.com>
vfio/pci: implement get_tph and DMA_BUF_TPH feature
This commit implements dma-buf get_tph for vfio-pci exported dma-bufs and
adds the VFIO_DEVICE_FEATURE_DMA_BUF_TPH feature. This allows userspace to
publish TPH metadata for a VFIO-owned device. It checks completer support
and protects the metadata under dmabuf->resv.
> diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
> index 1a177ce7de546..0a0705c8dbea6 100644
> --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
[ ... ]
> @@ -333,6 +360,71 @@ int vfio_pci_core_feature_dma_buf(struct vfio_pci_core_device *vdev, u32 flags,
> return ret;
> }
>
> +int vfio_pci_core_feature_dma_buf_tph(struct vfio_pci_core_device *vdev,
> + u32 flags,
> + struct vfio_device_feature_dma_buf_tph __user *arg,
> + size_t argsz)
> +{
> + struct vfio_device_feature_dma_buf_tph set_tph;
> + struct vfio_pci_dma_buf *priv;
> + struct dma_buf *dmabuf;
> + u8 comp;
> + int ret;
> +
> + ret = vfio_check_feature(flags, argsz, VFIO_DEVICE_FEATURE_SET,
> + sizeof(set_tph));
> + if (ret != 1)
> + return ret;
[Severity: Medium]
vfio_check_feature() returns 0 for VFIO_DEVICE_FEATURE_PROBE, causing an
early return of success.
Should the hardware capability check (pcie_tph_completer_type) occur before
checking the feature flags, to avoid falsely reporting that the feature is
supported on devices that lack TPH?
> +
> + if (copy_from_user(&set_tph, arg, sizeof(set_tph)))
> + return -EFAULT;
> +
> + if (set_tph.flags & ~(VFIO_DMA_BUF_TPH_ST | VFIO_DMA_BUF_TPH_ST_EXT))
> + return -EINVAL;
> +
> + if (set_tph.ph & ~0x3)
> + return -EINVAL;
[Severity: Medium]
When userspace clears the TPH metadata by passing flags == 0, is it required
to zero-fill the unused ph field?
Since this check is unconditional, could stack garbage in the uninitialized
ph field cause spurious -EINVAL errors, rejecting a valid invalidation
request?
> +
> + comp = pcie_tph_completer_type(vdev->pdev);
> + if (comp == PCI_EXP_DEVCAP2_TPH_COMP_NONE)
> + return -EOPNOTSUPP;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610193158.2614209-1-zhipingz@meta.com?part=4
next prev parent reply other threads:[~2026-06-11 20:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-10 19:31 [PATCH v7 0/5] vfio/dma-buf: add TPH support for peer-to-peer access Zhiping Zhang
2026-06-10 19:31 ` [PATCH v7 1/5] net/mlx5: free mlx5_st_idx_data on final dealloc Zhiping Zhang
2026-06-11 7:47 ` Christian König
2026-06-11 22:53 ` Zhiping Zhang
2026-06-11 23:45 ` Zhiping Zhang
2026-06-11 20:25 ` sashiko-bot
2026-06-11 22:54 ` Zhiping Zhang
2026-06-10 19:31 ` [PATCH v7 2/5] PCI/TPH: Add requester/completer type helpers Zhiping Zhang
2026-06-11 20:25 ` sashiko-bot
2026-06-11 23:06 ` Zhiping Zhang
2026-06-10 19:31 ` [PATCH v7 3/5] dma-buf: add optional get_tph() callback Zhiping Zhang
2026-06-11 10:35 ` Christian König
2026-06-11 23:07 ` Zhiping Zhang
2026-06-11 20:26 ` sashiko-bot
2026-06-10 19:31 ` [PATCH v7 4/5] vfio/pci: implement get_tph and DMA_BUF_TPH feature Zhiping Zhang
2026-06-11 20:25 ` sashiko-bot [this message]
2026-06-11 23:02 ` Zhiping Zhang
2026-06-12 16:59 ` Alex Williamson
2026-06-10 19:31 ` [PATCH v7 5/5] RDMA/mlx5: get tph for p2p access when registering dma-buf mr Zhiping Zhang
2026-06-11 12:44 ` Michael Gur
2026-06-11 23:09 ` Zhiping Zhang
2026-06-11 20:26 ` sashiko-bot
-- strict thread matches above, loose matches on Subject: below --
2026-06-11 16:11 [PATCH v7 0/5] vfio/dma-buf: add TPH support for peer-to-peer access Zhiping Zhang
2026-06-11 16:11 ` [PATCH v7 4/5] vfio/pci: implement get_tph and DMA_BUF_TPH feature Zhiping Zhang
2026-06-12 16:46 ` sashiko-bot
2026-06-12 17:10 ` Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260611202555.B0FE31F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kvm@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=zhipingz@meta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.