From: sashiko-bot@kernel.org
To: "Niklas Cassel" <cassel@kernel.org>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI: Update saved Max Read Request Size in pcie_set_readrq()
Date: Tue, 13 Oct 2026 20:05:19 +0000 [thread overview]
Message-ID: <sashiko-outbox-170438@kernel.org> (raw)
In-Reply-To: <20261013195307.181647-2-cassel@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] pci: Data race in pcie_set_readrq() corrupts hardware and saved state
--
commit 5cff2e9dcd50378ba11b9189a892c4623d8503cd
Author: Niklas Cassel <cassel@kernel.org>
PCI: Update saved Max Read Request Size in pcie_set_readrq()
This commit updates pcie_set_readrq() to also modify the kernel's saved copy
of the Device Control register when changing the Max Read Request Size. This
ensures that pci_restore_state() restores the intended MRRS value after a
device reset or error recovery.
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -5944,8 +5944,12 @@ int pcie_set_readrq(struct pci_dev *dev, int rq)
>
> ret = pcie_capability_clear_and_set_word(dev, PCI_EXP_DEVCTL,
> PCI_EXP_DEVCTL_READRQ, v);
> + if (ret)
> + return pcibios_err_to_errno(ret);
>
> - return pcibios_err_to_errno(ret);
> + pcie_update_saved_devctl(dev, PCI_EXP_DEVCTL_READRQ, v);
[Severity: Medium]
Can this introduce a data race when called concurrently?
Looking at the newly added pcie_update_saved_devctl(), it performs an
unlocked read-modify-write on the saved state memory:
drivers/pci/pci.c:pcie_update_saved_devctl() {
...
devctl = (u16 *)&save_state->cap.data[0];
*devctl = (*devctl & ~clear) | set;
}
Both the hardware register write via pcie_capability_clear_and_set_word()
(which drops to the unlocked variant for PCI_EXP_DEVCTL) and this new state
update appear to happen without synchronization.
Concurrent access seems possible via VFIO, which allows parallel lockless
pwrite() calls to the PCI Express capability region. This routes through:
vfio_device_fops_write()
vfio_pci_core_write()
vfio_exp_config_write()
pcie_set_readrq()
Could concurrent user-space writes corrupt both the hardware register and the
cached state memory, causing pci_restore_state() to mistakenly restore
invalid state later?
> +
> + return 0;
> }
> EXPORT_SYMBOL(pcie_set_readrq);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261013195307.181647-2-cassel@kernel.org?part=1
next prev parent reply other threads:[~2026-10-13 20:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 19:53 [PATCH] PCI: Update saved Max Read Request Size in pcie_set_readrq() Niklas Cassel
2026-10-13 20:05 ` sashiko-bot [this message]
2026-10-13 21:00 ` Niklas Cassel
2026-10-14 2:21 ` Shawn Lin
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-170438@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=cassel@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 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.