From: sashiko-bot@kernel.org
To: "Srirangan Madhavan" <smadhavan@nvidia.com>,
linux-cxl@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v17 15/19] PCI/CXL: Restore CXL state after PCI reset
Date: Thu, 05 Nov 2026 19:34:46 +0000 [thread overview]
Message-ID: <sashiko-outbox-199929@kernel.org> (raw)
In-Reply-To: <20261105185917.2667656-16-smadhavan@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] PCI/CXL: cxl_reset_quiesced() skips disabling device if cache restore fails
--
commit 0833e3bda8d31d8ddf0c1310990a9ee4b81a1760
Author: Srirangan Madhavan <smadhavan@nvidia.com>
PCI/CXL: Restore CXL state after PCI reset
This commit restores PCI configuration, cached HDM decoder settings, and CXL
Device DVSEC control state after a CXL device reset. If any restoration step
fails, it disables the device and updates the saved PCI command state so the
outer PCI reset flow does not re-enable memory decoding or bus mastering.
> diff --git a/drivers/pci/cxl.c b/drivers/pci/cxl.c
> index c07266ab01336..77d0e30841d9f 100644
> --- a/drivers/pci/cxl.c
> +++ b/drivers/pci/cxl.c
[ ... ]
> @@ -415,7 +572,9 @@ static int cxl_clear_memory(struct pci_dev *pdev, int dvsec, bool initiate)
> }
>
> static int __cxl_reset_execute(struct pci_dev *pdev, int dvsec, u16 cap,
> - struct cxl_hdm_quiesce *q)
> + const struct cxl_hdm_info *snapshot,
> + struct cxl_hdm_quiesce *q,
> + u16 *command)
> __must_hold(cxl_region_quiesce)
> {
> int rc, rc2;
> @@ -441,10 +600,15 @@ static int __cxl_reset_execute(struct pci_dev *pdev, int dvsec, u16 cap,
> pci_err(pdev, "failed to clear CXL Reset Memory Clear: %d\n", rc2);
> rc = rc ?: rc2;
>
> + if (!rc)
> + rc = pci_cxl_restore_state(pdev, snapshot, command);
> +
> rc2 = cxl_hdm_quiesce_flush(q);
> if (rc2)
> pci_err(pdev, "failed to invalidate CPU cache after CXL reset: %d\n", rc2);
> rc = rc ?: rc2;
> + if (rc)
> + cxl_reset_save_disabled_state(pdev);
>
> pci_dev_reset_iommu_done(pdev);
> return rc;
> @@ -455,6 +619,7 @@ static int cxl_reset_quiesced(struct pci_dev *pdev, int dvsec, u16 cap)
> {
> struct cxl_hdm_info *snapshot __free(kfree) = NULL;
> struct cxl_pci_cache cache = {};
> + u16 command;
> int rc, rc2;
>
> rc = pci_read_config_word(pdev, dvsec + PCI_DVSEC_CXL_CTRL2,
> @@ -478,11 +643,19 @@ static int cxl_reset_quiesced(struct pci_dev *pdev, int dvsec, u16 cap)
> return rc;
> }
> if (!rc)
> - rc = __cxl_reset_execute(pdev, dvsec, cap, &cache.quiesce);
> + rc = __cxl_reset_execute(pdev, dvsec, cap, snapshot, &cache.quiesce,
> + &command);
> /* Restore cache policy after any attempt to disable caching. */
> rc2 = cxl_reset_restore_cache_policy(pdev, dvsec, cache.saved_ctrl2);
> cxl_hdm_quiesce_destroy(&cache.quiesce);
> - return rc ?: rc2;
> + if (rc)
> + return rc;
> + if (rc2) {
> + cxl_reset_save_disabled_state(pdev);
> + return rc2;
> + }
[Severity: Medium]
In drivers/pci/cxl.c:cxl_reset_quiesced(), can returning early on if (rc)
before checking if (rc2) skip calling cxl_reset_save_disabled_state(pdev) when
restoring the CXL cache policy also fails?
Specifically, rc can be non-zero before cxl_reset_save_disabled_state(pdev) is
reached in two cases after CXL caching has been disabled:
1. cxl_reset_cache_prepare() sets cache.cache_disabled = true and disables
caching via cxl_reset_disable_cache(), but cxl_reset_wait_cache_wbi() then
fails.
2. cxl_reset_cache_prepare() succeeds, and __cxl_reset_execute() returns early
from pci_wait_for_pending_transaction() or pci_dev_reset_iommu_prepare()
before reaching cxl_reset_save_disabled_state(pdev) at the end of
__cxl_reset_execute():
drivers/pci/cxl.c:__cxl_reset_execute() {
if (!pci_wait_for_pending_transaction(pdev)) {
pci_err(pdev, "timed out waiting for pending transactions\n");
return -ETIMEDOUT;
}
rc = pci_dev_reset_iommu_prepare(pdev);
if (rc) {
pci_err(pdev, "failed to stop IOMMU for CXL reset: %d\n", rc);
return rc;
}
...
}
In either case, pdev->saved_config_space[PCI_COMMAND / 4] still holds the
pre-reset MSE and BME bits. If cxl_reset_restore_cache_policy() then fails
(rc2 != 0), checking if (rc) first returns without calling
cxl_reset_save_disabled_state(pdev), allowing the outer PCI reset path to
re-enable memory decoding and bus mastering on a device whose CXL cache policy
in PCI_DVSEC_CXL_CTRL2 was not restored.
Should the if (rc2) check call cxl_reset_save_disabled_state(pdev) before
returning rc?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261105185917.2667656-1-smadhavan@nvidia.com?part=15
next prev parent reply other threads:[~2026-11-05 19:34 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 18:58 [PATCH v17 00/19] PCI/CXL: Add CXL reset support for Type 2 devices Srirangan Madhavan
2026-11-05 18:58 ` [PATCH v17 01/19] cxl: Clarify decoder interleave limit Srirangan Madhavan
2026-11-05 19:03 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 02/19] cxl: Share CXL port upstream PCI device lookup Srirangan Madhavan
2026-11-05 19:12 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 03/19] cxl: Move decoder declarations to shared header Srirangan Madhavan
2026-11-05 19:06 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 04/19] cxl: Embed decoder configuration in a standalone structure Srirangan Madhavan
2026-11-05 19:07 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 05/19] cxl: Introduce endpoint HDM decoder settings Srirangan Madhavan
2026-11-05 19:09 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 06/19] cxl: Move HDM decoder helpers to built-in code Srirangan Madhavan
2026-11-05 19:07 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 07/19] cxl: Share HDM decoder register unpacking Srirangan Madhavan
2026-11-05 19:16 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 08/19] cxl: Move cxl_rwsem into built-in code Srirangan Madhavan
2026-11-05 19:09 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 09/19] cxl: Refresh cached PCI HDM decoder settings Srirangan Madhavan
2026-11-05 19:17 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 10/19] cxl: Build register block helpers into the kernel Srirangan Madhavan
2026-11-05 19:23 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 11/19] PCI/CXL: Cache endpoint HDM state during PCI enumeration Srirangan Madhavan
2026-11-05 19:30 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 12/19] PCI/CXL: Add CXL Device Reset sequencing Srirangan Madhavan
2026-11-05 19:17 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 13/19] cxl: Validate and synchronize HDM ranges around reset Srirangan Madhavan
2026-11-05 19:44 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 14/19] PCI/CXL: Reject reset with unsafe function scope Srirangan Madhavan
2026-11-05 19:33 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 15/19] PCI/CXL: Restore CXL state after PCI reset Srirangan Madhavan
2026-11-05 19:34 ` sashiko-bot [this message]
2026-11-05 18:59 ` [PATCH v17 16/19] PCI/CXL: Expose CXL Reset as a PCI reset method Srirangan Madhavan
2026-11-05 19:35 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 17/19] PCI/CXL: Restore CXL state after CXL bus reset Srirangan Madhavan
2026-11-05 19:43 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 18/19] PCI/CXL: Flush host and device caches for " Srirangan Madhavan
2026-11-05 19:56 ` sashiko-bot
2026-11-05 18:59 ` [PATCH v17 19/19] cxl: Add KUnit checks for HDM decoder unpacking Srirangan Madhavan
2026-11-05 19:38 ` sashiko-bot
2026-11-05 19:31 ` [PATCH v17 00/19] PCI/CXL: Add CXL reset support for Type 2 devices Alison Schofield
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=sashiko-outbox-199929@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=smadhavan@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox