From: sashiko-bot@kernel.org
To: "Priyank Rathod" <rathodpriyank@google.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v5 1/2] PCI/LMR: Add Lane Margining at the Receiver debugfs interface
Date: Tue, 06 Oct 2026 17:45:34 +0000 [thread overview]
Message-ID: <sashiko-outbox-162306@kernel.org> (raw)
In-Reply-To: <20261006-pcie-link-endpoints-v5-1-c1e73235746b@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] pci: pci_lmr_reboot_notify skips lane reset on trylock failure
--
commit 1dd16e08c517390b6bc52a453ae7eeb35b21f5e3
Author: Priyank Rathod <rathodpriyank@google.com>
PCI/LMR: Add Lane Margining at the Receiver debugfs interface
This commit introduces a debugfs interface for PCIe Lane Margining at the
Receiver, enabling user-space to configure sampling point offsets and read
error counts. It also adds logic to disable ASPM and hardware autonomous
speed/width during an active margining session.
> diff --git a/drivers/pci/pcie/margin.c b/drivers/pci/pcie/margin.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/pci/pcie/margin.c
[ ... ]
> +/* Return margined lanes to normal settings before reboot or kexec */
> +static int pci_lmr_reboot_notify(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct pci_lmr_port *port;
> +
> + guard(mutex)(&pci_lmr_mutex);
> + list_for_each_entry(port, &pci_lmr_ports, node) {
> + if (port->state != LMR_ACTIVE)
> + continue;
> + if (!mutex_trylock(&port->lock))
> + continue;
[Severity: Medium]
If this mutex_trylock() fails, does this code skip the hardware restore steps?
If a system reboot or kexec is initiated while a user-space tool is actively
margining a PCIe link, the margining thread may be holding port->lock
(which can block for up to 100ms waiting for hardware responses).
When this trylock fails, the notifier silently continues, skipping both the
lane reset (pci_lmr_reset_lanes) and the restoration of hardware autonomous
width/speed settings (pci_lmr_autonomous_restore).
Because kexec does not assert PERST# to fully reset the PCIe link, could the
new kernel inherit a link with shifted margins and disabled autonomous
management, potentially leading to link instability and missing devices?
> + if (port->state == LMR_ACTIVE) {
> + if (!pci_dev_is_disconnected(port->dev))
> + pci_lmr_reset_lanes(port);
> + pci_lmr_autonomous_restore(port);
> + }
> + mutex_unlock(&port->lock);
> + }
> +
> + return NOTIFY_DONE;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261006-pcie-link-endpoints-v5-0-c1e73235746b@google.com?part=1
next prev parent reply other threads:[~2026-10-06 17:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 17:34 [PATCH v5 0/2] PCI: Add Lane Margining at the Receiver debugfs interface Priyank Rathod
2026-10-06 17:34 ` [PATCH v5 1/2] PCI/LMR: " Priyank Rathod
2026-10-06 17:45 ` sashiko-bot [this message]
2026-10-06 17:34 ` [PATCH v5 2/2] selftests/pcie_lmr: Add tests for the Lane Margining " Priyank Rathod
2026-10-06 17:40 ` sashiko-bot
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-162306@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rathodpriyank@google.com \
--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.