[{"id":3688723,"web_url":"http://patchwork.ozlabs.org/comment/3688723/","msgid":"<20260508204652.F0A71C2BCF4@smtp.kernel.org>","list_archive_url":null,"date":"2026-05-08T20:46:52","subject":"Re: [PATCH v8 5/7] vfio/pci: Add PCIe TPH enable/disable support","submitter":{"id":93311,"url":"http://patchwork.ozlabs.org/api/people/93311/","name":null,"email":"sashiko-bot@kernel.org"},"content":"Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:\n- [High] TPH operations access the device's PCI configuration space without ensuring the device is in the D0 power state, risking accesses while suspended (D3).\n- [High] `vdev->igate` is insufficient to prevent bitfield tearing on `pdev->tph_enabled` against other PCI subsystems.\n--\n\ncommit e6a89cf03d6c51144466205cce4a3bf38731b5db\nAuthor: Chengwen Feng \n\nvfio/pci: Add PCIe TPH enable/disable support\n\nThis patch adds support for enabling and disabling the TPH function via\nmode selection. It also disables TPH when ownership is taken or when\nuserspace closes the device FD.\n\n> Serialize all TPH operations under vdev->igate mutex using scope-based\n> automatic locking to prevent hardware control and bitfield races.\n\nIf pdev->tph_enabled is a bitfield inside struct pci_dev that shares a\nmemory word with other core PCI bitfields (like state_saved or\nis_busmaster), will vdev->igate prevent bitfield tearing?\n\nSince other kernel subsystems modify these neighboring bitfields without\nholding the VFIO-private igate mutex (such as the PCI PM core modifying\nstate_saved during runtime suspend), concurrent updates could result in\ndata races and lost state updates.\n\n> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c\n> index 0e97b128fd637..bfc7e87d190f4 100644\n> --- a/drivers/vfio/pci/vfio_pci_core.c\n> +++ b/drivers/vfio/pci/vfio_pci_core.c\n> @@ -738,6 +738,9 @@ void vfio_pci_core_close_device(struct vfio_device *core_vdev)\n> #endif\n> \tvfio_pci_dma_buf_cleanup(vdev);\n> \n> +\t/* Disable TPH when userspace closes the device FD */\n> +\tpcie_disable_tph(vdev->pdev);\n> +\n> \tvfio_pci_core_disable(vdev);\n\nIs it safe to access the device's PCI configuration space here?\n\nSince vfio_pci_core_disable() is explicitly responsible for waking up the\ndevice via pm_runtime_resume(), pcie_disable_tph() is being called before\nthe device is ensured to be in the D0 power state. \n\nAccessing the config space of a suspended device could cause PCIe errors\nlike Unsupported Requests.\n\n[ ... ]\n\n> \tswitch (op.op) {\n> \tcase VFIO_PCI_TPH_GET_CAP:\n> \t\treturn vfio_pci_tph_get_cap(vdev, &op, uarg + minsz);\n> +\tcase VFIO_PCI_TPH_ENABLE:\n> +\t\treturn vfio_pci_tph_enable(vdev, &op, uarg + minsz);\n> +\tcase VFIO_PCI_TPH_DISABLE:\n> +\t\treturn vfio_pci_tph_disable(vdev);\n\nAre these TPH capability accesses safe without a pm_runtime_resume_and_get()\nand pm_runtime_put() wrapper?\n\nUserspace could potentially access the config space while the device is idle\nand runtime suspended.\n\n[ ... ]\n\n> @@ -2257,6 +2302,9 @@ int vfio_pci_core_register_device(struct vfio_pci_core_device *vdev)\n> \tif (!disable_idle_d3)\n> \t\tpm_runtime_put(dev);\n> \n> +\t/* Disable TPH when taking over ownership of the device */\n> +\tpcie_disable_tph(pdev);\n> +\n\nCould this pcie_disable_tph() execute while the device is suspending?\n\nIt is called after pm_runtime_put(), meaning the PM core may have already\nstarted asynchronously suspending the device, potentially leading to config\nspace accesses while the device is in D3.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=E6BbsElJ;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=104.64.211.4; helo=sin.lore.kernel.org;\n envelope-from=linux-pci+bounces-54288-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"E6BbsElJ\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sin.lore.kernel.org (sin.lore.kernel.org [104.64.211.4])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4gC1Pv6B2vz1yK7\n\tfor ; Sat, 09 May 2026 06:46:59 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 1C96430072B0\n\tfor ; Fri, 8 May 2026 20:46:57 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 39CB73890EA;\n\tFri, 8 May 2026 20:46:55 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 2756335AC01\n\tfor ; Fri, 8 May 2026 20:46:53 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id F0A71C2BCF4;\n\tFri, 8 May 2026 20:46:52 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778273214; cv=none;\n b=bYleiRxDOx0wyDJ84riDDpcV7GcGE5pjA+xZiz7/50vOTvgjp5OdwBvRZsbhyNzhay4JfBU3+xl7L15Kkm9W8v/RhtebTPEFlpRyoyL2qvxKIy0sz4Jb1nKK90lzOsu37bQM0YCM62dclF2I1wRFBmm6lunq5AsMSgT5R9Db8Tc=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778273214; c=relaxed/simple;\n\tbh=SwGiKEfKroqIggk9fVheRXzU+cSwwRWydHc5j+s/kCo=;\n\th=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date:\n\t Message-Id;\n b=CWYiPWSpcJtMYIy6KFKXeYecXCATZg8l1I4t4aWM6Sb6cFca+p9LrOiKEYfGkeHo1lTHb1A23vI1Ry+slMXWG4NO4RZ1uOOsCOo6f4EfVsJ/lbjl1xiDw739zb2lq35cj3Sk1mawc6w3U6iwKjjIkxr2PLCxtTmSFxBIvF+KG0s=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=E6BbsElJ; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1778273213;\n\tbh=SwGiKEfKroqIggk9fVheRXzU+cSwwRWydHc5j+s/kCo=;\n\th=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From;\n\tb=E6BbsElJSsC8v3Agg3KTgrMbntHjhror5HYFkXY5zoxe+dwv8VGFsJMI3TXXPNd9N\n\t CgyYLHClJpY7/g3OicqMf+cwRDJcEvN/URx492771Axl0KwkBYONQ+Br3NcNmDXMdi\n\t IxIfYXle77AaRVpU7r6XMFB3/NSgB5Or2ZWsPSGKPp6eCrPhXgMopARrGnFeKFvjoa\n\t qsUHxWbMQVmRQz7CGil9/6ENDLM/Jk5GSqznJ5RjCSSx/8Y6rAPk+xCKdmfuau2lGu\n\t AYNCdO79uQmhqN4IVYzfJT/HQprInkR+mGsC0FAizg8/1lNTtgPG724Q4t6haaQ3A1\n\t 2Oq4WVthj+42A==","From":"sashiko-bot@kernel.org","Subject":"Re: [PATCH v8 5/7] vfio/pci: Add PCIe TPH enable/disable support","Reply-To":"sashiko@lists.linux.dev","To":"\"Chengwen Feng\" ","Cc":"linux-pci@vger.kernel.org","In-Reply-To":"<20260508064053.37529-6-fengchengwen@huawei.com>","References":"<20260508064053.37529-6-fengchengwen@huawei.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","Date":"Fri, 08 May 2026 20:46:52 +0000","Message-Id":"<20260508204652.F0A71C2BCF4@smtp.kernel.org>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":""}}]