From: sashiko-bot@kernel.org
To: "Farhan Ali" <alifm@linux.ibm.com>
Cc: "Vasily Gorbik" <gor@linux.ibm.com>,
linux-pci@vger.kernel.org,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
linux-s390@vger.kernel.org
Subject: Re: [PATCH v21 2/4] PCI: Avoid saving config space state if inaccessible
Date: Tue, 30 Jun 2026 17:07:53 +0000 [thread overview]
Message-ID: <20260630170754.093021F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260630164807.643-3-alifm@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] pci_dev_save_and_disable() skips disabling the device if config space is momentarily inaccessible, potentially leaving DMA and interrupts enabled.
- [Low] String literal passed to a non-const `char *` pointer in `pci_dev_config_accessible()`.
--
commit 067c10f20c7b3c97acf8c9886f6586c07bea7142
Author: Farhan Ali <alifm@linux.ibm.com>
PCI: Avoid saving config space state if inaccessible
This commit avoids saving the device's config space state during a reset
if the device config space is temporarily inaccessible, preventing invalid
values from being written back later.
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -713,6 +713,27 @@ u16 pci_find_dvsec_capability(struct pci_dev *dev, u16 vendor, u16 dvsec)
> }
> EXPORT_SYMBOL_GPL(pci_find_dvsec_capability);
>
> +static bool pci_dev_config_accessible(struct pci_dev *dev, char *msg)
[Severity: Low]
This isn't a bug, but should the msg parameter be marked const?
Since a string literal ("save state") is passed to this function, keeping
it as a non-const pointer violates const-correctness and might trigger
compiler warnings.
> +{
> + u32 val;
> +
[ ... ]
> @@ -5059,6 +5080,9 @@ static void pci_dev_save_and_disable(struct pci_dev *dev)
> */
> pci_set_power_state(dev, PCI_D0);
>
> + if (!pci_dev_config_accessible(dev, "save state"))
> + return;
> +
[Severity: High]
Does this early return skip disabling the device entirely if the config
space is momentarily inaccessible?
If the device is only transiently inaccessible and recovers immediately
after the pci_dev_config_accessible() check, this early return skips the
subsequent pci_write_config_word() that clears the Command register.
Could this leave the device with Bus Master enabled, potentially allowing
it to generate unexpected DMA requests or interrupt storms during the
reset sequence?
> pci_save_state(dev);
> /*
> * Disable the device by clearing the Command register, except for
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630164807.643-1-alifm@linux.ibm.com?part=2
next prev parent reply other threads:[~2026-06-30 17:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 16:48 [PATCH v21 0/4] [PCI] Error recovery for vfio-pci devices on s390x Farhan Ali
2026-06-30 16:48 ` [PATCH v21 1/4] PCI: Allow per function PCI slots to fix slot reset on s390 Farhan Ali
2026-06-30 17:10 ` sashiko-bot
2026-06-30 16:48 ` [PATCH v21 2/4] PCI: Avoid saving config space state if inaccessible Farhan Ali
2026-06-30 17:07 ` sashiko-bot [this message]
2026-06-30 16:48 ` [PATCH v21 3/4] PCI: Fail FLR when config space is inaccessible Farhan Ali
2026-06-30 17:13 ` sashiko-bot
2026-06-30 16:48 ` [PATCH v21 4/4] PCI/MSI: Enable memory decoding before restoring MSI-X messages Farhan Ali
2026-06-30 17:12 ` sashiko-bot
2026-07-13 18:21 ` [PATCH v21 0/4] [PCI] Error recovery for vfio-pci devices on s390x Farhan Ali
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=20260630170754.093021F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=alifm@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-pci@vger.kernel.org \
--cc=linux-s390@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 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.