From: sashiko-bot@kernel.org
To: "Chengwen Feng" <fengchengwen@huawei.com>
Cc: kvm@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v19 12/18] vfio/pci: Add dmabuf TPH metadata storage and fd query helper
Date: Thu, 02 Jul 2026 12:56:23 +0000 [thread overview]
Message-ID: <20260702125624.1AB531F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260702124224.57168-13-fengchengwen@huawei.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] vfio_pci_dma_buf_get_tph_by_fd() fails to acquire the dma_resv lock before calling vfio_pci_dma_buf_get_pci_tph(), leading to a guaranteed lockdep splat and a potential data race.
--
commit cb20e399309e26c4cb897d3a87f672443b48caa4
Author: Chengwen Feng <fengchengwen@huawei.com>
vfio/pci: Add dmabuf TPH metadata storage and fd query helper
This commit adds TPH metadata fields to vfio_pci_dma_buf to store
PH and ST information along with their validity flags. It also implements
helpers to fetch this metadata from a dmabuf, providing the foundation
for upcoming TPH resolution features.
> diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
> index c16f460c01d68..d9c5e434e586f 100644
> --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
[ ... ]
> @@ -81,6 +88,26 @@ static void vfio_pci_dma_buf_unmap(struct dma_buf_attachment *attachment,
> kref_put(&priv->kref, vfio_pci_dma_buf_done);
> }
>
> +static int vfio_pci_dma_buf_get_pci_tph(struct dma_buf *dmabuf, bool extended,
> + u16 *tag, u8 *ph)
> +{
> + struct vfio_pci_dma_buf *priv = dmabuf->priv;
> +
> + dma_resv_assert_held(priv->dmabuf->resv);
> +
> + if (extended) {
[ ... ]
> @@ -106,6 +133,26 @@ static const struct dma_buf_ops vfio_pci_dmabuf_ops = {
> .release = vfio_pci_dma_buf_release,
> };
>
> +int vfio_pci_dma_buf_get_tph_by_fd(int fd, bool extended, u16 *tag, u8 *ph)
> +{
> + struct dma_buf *dmabuf;
> + int ret = 0;
> +
> + dmabuf = dma_buf_get(fd);
> + if (IS_ERR(dmabuf))
> + return PTR_ERR(dmabuf);
> +
> + if (dmabuf->ops != &vfio_pci_dmabuf_ops) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + ret = vfio_pci_dma_buf_get_pci_tph(dmabuf, extended, tag, ph);
[Severity: High]
Is it necessary to acquire the dmabuf->resv lock before making this call?
Since vfio_pci_dma_buf_get_pci_tph() asserts the lock is held, it seems
invoking it directly from here will guarantee a lockdep splat.
It also appears this could leave the read of the TPH metadata bitfields
unprotected against concurrent updates, resulting in a data race.
> +out:
> + dma_buf_put(dmabuf);
> + return ret;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260702124224.57168-1-fengchengwen@huawei.com?part=12
next prev parent reply other threads:[~2026-07-02 12:56 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 12:42 [PATCH v19 00/18] vfio/pci: Add PCIe TPH support Chengwen Feng
2026-07-02 12:42 ` [PATCH v19 01/18] PCI/TPH: Fix pcie_tph_get_st_table_loc() field extraction Chengwen Feng
2026-07-02 12:51 ` sashiko-bot
2026-07-02 12:42 ` [PATCH v19 02/18] PCI/TPH: Fix tph_enabled concurrent update race by bitfield packing Chengwen Feng
2026-07-02 12:51 ` sashiko-bot
2026-07-02 12:42 ` [PATCH v19 03/18] PCI/TPH: Cache TPH requester capability at probe time Chengwen Feng
2026-07-02 12:55 ` sashiko-bot
2026-07-02 12:42 ` [PATCH v19 04/18] PCI/TPH: Refactor pcie_enable_tph & add explicit requester variant Chengwen Feng
2026-07-02 12:50 ` sashiko-bot
2026-07-02 12:42 ` [PATCH v19 05/18] PCI/TPH: Refactor pcie_tph_get_cpu_st & add explicit variant Chengwen Feng
2026-07-02 12:56 ` sashiko-bot
2026-07-02 12:42 ` [PATCH v19 06/18] PCI/TPH: Expose the enabled TPH requester type Chengwen Feng
2026-07-02 12:49 ` sashiko-bot
2026-07-02 12:42 ` [PATCH v19 07/18] PCI/TPH: Add pcie_tph_supported() helper to check TPH capability attributes Chengwen Feng
2026-07-02 12:53 ` sashiko-bot
2026-07-03 0:39 ` fengchengwen
2026-07-02 12:42 ` [PATCH v19 08/18] PCI/TPH: Add pci_tph_dsm_supported() helper to detect device TPH ST _DSM Chengwen Feng
2026-07-02 12:55 ` sashiko-bot
2026-07-02 12:42 ` [PATCH v19 09/18] vfio/pci: Hide TPH capability when TPH is unsupported Chengwen Feng
2026-07-02 13:00 ` sashiko-bot
2026-07-03 0:36 ` fengchengwen
2026-07-02 12:42 ` [PATCH v19 10/18] vfio/pci: Introduce tph policy parameter for staged TPH feature enablement Chengwen Feng
2026-07-02 12:50 ` sashiko-bot
2026-07-02 12:42 ` [PATCH v19 11/18] vfio/pci: Virtualize PCIe TPH capability registers Chengwen Feng
2026-07-02 13:04 ` sashiko-bot
2026-07-03 0:51 ` fengchengwen
2026-07-02 12:42 ` [PATCH v19 12/18] vfio/pci: Add dmabuf TPH metadata storage and fd query helper Chengwen Feng
2026-07-02 12:56 ` sashiko-bot [this message]
2026-07-03 0:53 ` fengchengwen
2026-07-02 12:42 ` [PATCH v19 13/18] vfio/pci: Introduce VFIO_DEVICE_FEATURE_TPH family uapi for PCI TPH control Chengwen Feng
2026-07-02 13:01 ` sashiko-bot
2026-07-03 0:57 ` fengchengwen
2026-07-02 12:42 ` [PATCH v19 14/18] vfio/pci: Implement VFIO_DEVICE_FEATURE_TPH and valid TPH config write support Chengwen Feng
2026-07-02 13:04 ` sashiko-bot
2026-07-03 1:16 ` fengchengwen
2026-07-02 12:42 ` [PATCH v19 15/18] vfio/pci: Implement TPH_RESOLVE feature for DMABUF and CPU source resolving Chengwen Feng
2026-07-02 13:00 ` sashiko-bot
2026-07-03 1:26 ` fengchengwen
2026-07-02 12:42 ` [PATCH v19 16/18] vfio/pci: Implement TPH_ST feature for batch ST table programming Chengwen Feng
2026-07-02 13:04 ` sashiko-bot
2026-07-03 1:42 ` fengchengwen
2026-07-02 12:42 ` [PATCH v19 17/18] vfio/pci: Reset hardware TPH state on device enable/disable Chengwen Feng
2026-07-02 13:00 ` sashiko-bot
2026-07-02 12:42 ` [PATCH v19 18/18] vfio/pci: Expose tph_policy via debugfs Chengwen Feng
2026-07-02 12:59 ` sashiko-bot
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=20260702125624.1AB531F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=fengchengwen@huawei.com \
--cc=kvm@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox