[{"id":3688687,"web_url":"http://patchwork.ozlabs.org/comment/3688687/","msgid":"<20260508190228.85506C2BD01@smtp.kernel.org>","list_archive_url":null,"date":"2026-05-08T19:02:27","subject":"Re: [PATCH v8 2/7] PCI/TPH: Export pcie_tph_get_st_modes() for\n external use","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 1 potential issue(s) to consider:\n- [High] pcie_tph_get_st_modes() and pcie_tph_get_st_table_loc() do not check the return value of pci_read_config_dword(), causing them to return false capabilities on read failures.\n--\n\ncommit 521881ea093ae852c8fad775f8ffcbe3b9c7a46b\nAuthor: Chengwen Feng \n\nPCI/TPH: Export pcie_tph_get_st_modes() for external use\n\nThis commit exports the pcie_tph_get_st_modes() helper to allow external\ndrivers like VFIO to query supported PCIe TPH steering tag modes. It also\nadds stub functions for when CONFIG_PCIE_TPH is disabled and includes\ntph_cap validation to prevent invalid PCI configuration space access.\n\n> diff --git a/drivers/pci/tph.c b/drivers/pci/tph.c\n> index 877cf556242b4..ba31b010f67ad 100644\n> --- a/drivers/pci/tph.c\n> +++ b/drivers/pci/tph.c\n> @@ -145,15 +145,27 @@ static void set_ctrl_reg_req_en(struct pci_dev *pdev, u8 req_type)\n[ ... ]\n> -static u8 get_st_modes(struct pci_dev *pdev)\n> +/**\n> + * pcie_tph_get_st_modes - Get supported Steering Tag modes\n> + * @pdev: PCI device to query\n> + *\n> + * Return:\n> + * Bitmask of supported ST modes (PCI_TPH_CAP_ST_NS, PCI_TPH_CAP_ST_IV,\n> + * PCI_TPH_CAP_ST_DS)\n> + */\n> +u8 pcie_tph_get_st_modes(struct pci_dev *pdev)\n> {\n> \tu32 reg;\n> \n> +\tif (!pdev->tph_cap)\n> +\t\treturn 0;\n> +\n> \tpci_read_config_dword(pdev, pdev->tph_cap + PCI_TPH_CAP, ®);\n> \treg &= PCI_TPH_CAP_ST_NS | PCI_TPH_CAP_ST_IV | PCI_TPH_CAP_ST_DS;\n> \n> \treturn reg;\n> }\n\nIf pci_read_config_dword() fails (for example, if the device is disconnected\nor isolated), it sets the output variable reg to PCI_ERROR_RESPONSE (~0U).\n\nBecause the return value is not checked, this code will apply the bitmask\nto ~0U, which evaluates to 0x07 (PCI_TPH_CAP_ST_NS | PCI_TPH_CAP_ST_IV |\nPCI_TPH_CAP_ST_DS).\n\nSince this function is being exported for external use by drivers like VFIO,\ncould this falsely advertise that the device supports all three ST modes\ninstead of none? Should the return value of pci_read_config_dword() be\nchecked to ensure 0 is returned on failure?\n\n> +EXPORT_SYMBOL(pcie_tph_get_st_modes);\n> \n> /**\n> * pcie_tph_get_st_table_loc - Return the device's ST table location\n> @@ -168,6 +180,9 @@ u32 pcie_tph_get_st_table_loc(struct pci_dev *pdev)\n> {\n> \tu32 reg;\n> \n> +\tif (!pdev->tph_cap)\n> +\t\treturn PCI_TPH_LOC_NONE;\n> +\n> \tpci_read_config_dword(pdev, pdev->tph_cap + PCI_TPH_CAP, ®);\n> \n> \treturn reg & PCI_TPH_CAP_LOC_MASK;\n\nSimilarly, does an unchecked read failure here lead to returning an invalid\nlocation mask derived from the ~0U error response? Would it be safer to check\nthe return value and return PCI_TPH_LOC_NONE if the read fails?\n\n[ ... ]","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=asIhpky9;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.105.105.114; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-54280-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=\"asIhpky9\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org [172.105.105.114])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4gBzDD35Wkz1yCg\n\tfor ; Sat, 09 May 2026 05:08:28 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 8B97330D15D6\n\tfor ; Fri, 8 May 2026 19:02:49 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 414A5330305;\n\tFri, 8 May 2026 19:02:29 +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 1E09F423A85\n\tfor ; Fri, 8 May 2026 19:02:28 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 85506C2BD01;\n\tFri, 8 May 2026 19:02:28 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778266949; cv=none;\n b=Ln+4GX4juuIJQGynaN6Mny1vb3C2WsPfOeaw1E80zCaGoYFmdbOwyZaBdjzgZEo4zNmRfu+s1osvndfd9STfCeReAY/P+BqpaoIsusittWykNaTda14m0t4HPHNfW+ro6b6S3f69efGFSK7JoyVJngJGt97E+1yAI8Mfrl9g3r8=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778266949; c=relaxed/simple;\n\tbh=/sIVyftLqxYoxdkEqHlElojy7FaMvLL41mCvT4YtEbg=;\n\th=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date:\n\t Message-Id;\n b=mp4vhbtHa42hsHqWf9CNIJOGwLYVJzpCoe0d9NJtG7WzLRYBy45wkGcD1rcOoBXAU0K7FFrrzwMVcgbRTUHnFX4X1AHw0QWn+RWAV7w505crov2YWC+gkGbBDzDDHyWgVnIRcxmOmbJ4YoJ8P/jhJM0s/tQa866U7V2zwVtyOxA=","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=asIhpky9; 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=1778266948;\n\tbh=/sIVyftLqxYoxdkEqHlElojy7FaMvLL41mCvT4YtEbg=;\n\th=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From;\n\tb=asIhpky9s4dlM2JEwq7jQNxPm7lqFnSJt6w5Iw00nE4q8ej53/fJhEJ0uRU2EhFd2\n\t sasLmpVRK+sqzG4mtxdKr7gC9L0OyvC7qgTbubsVptMgsVwzIgPKnwx7AAfNcv9+Mo\n\t 1zpggIHX+9xx32ffr+IkCJc4KN2mWJcG5FwQEjSoIqiow4oD4t5N0QVdACDgiRkvMW\n\t oRHEl+WQvfTusfrRpNGycdNydBa14j7oFdMhSZLwo/DlmOEpwUKThxSYcGtMnh3/L4\n\t vZxbNp34eQHKCKsbFG4+LINuTMZ89LlliIcgnDY5Vtc7tfZtp8uGmjI2f81ncNK/ZU\n\t S5mhihBYHzF8w==","From":"sashiko-bot@kernel.org","Subject":"Re: [PATCH v8 2/7] PCI/TPH: Export pcie_tph_get_st_modes() for\n external use","Reply-To":"sashiko@lists.linux.dev","To":"\"Chengwen Feng\" ","Cc":"linux-pci@vger.kernel.org","In-Reply-To":"<20260508064053.37529-3-fengchengwen@huawei.com>","References":"<20260508064053.37529-3-fengchengwen@huawei.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","Date":"Fri, 08 May 2026 19:02:27 +0000","Message-Id":"<20260508190228.85506C2BD01@smtp.kernel.org>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":""}}]