From: sashiko-bot@kernel.org
To: "Narayana Murty N" <nnmlinux@linux.ibm.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v5 2/5] powerpc/pseries/eeh: Add RTAS error injection helpers
Date: Mon, 19 Oct 2026 10:34:22 +0000 [thread overview]
Message-ID: <sashiko-outbox-176997@kernel.org> (raw)
In-Reply-To: <20261019101813.45085-3-nnmlinux@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] powerpc/pseries/eeh: validate_addr_mask_in_pe() matches unassigned BARs
- [Low] powerpc/pseries/eeh: unused static helpers in eeh_pseries.c fail -Werror build
--
commit 0a875c4e62df7429dee888710961a7609ab3e1b1
Author: Narayana Murty N <nnmlinux@linux.ibm.com>
powerpc/pseries/eeh: Add RTAS error injection helpers
This patch adds helper functions to arch/powerpc/platforms/pseries/eeh_pseries.c
to translate generic EEH error types to RTAS encodings, validate error
injection arguments and PCI bus BAR addresses against the target PE, and
populate the PAPR ibm,errinjct work buffer.
> diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/powerpc/platforms/pseries/eeh_pseries.c
> index b12ef382fec70..999b3065e09b6 100644
> --- a/arch/powerpc/platforms/pseries/eeh_pseries.c
> +++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
[ ... ]
> @@ -786,6 +789,223 @@ static int pseries_notify_resume(struct eeh_dev *edev)
> }
> #endif
[ ... ]
> +static int validate_addr_mask_in_pe(struct eeh_pe *pe, unsigned long addr,
> + unsigned long mask)
> +{
[ ... ]
> + pci_lock_rescan_remove();
> + eeh_pe_for_each_dev(pe, edev, tmp) {
> + pdev = eeh_dev_to_pci_dev(edev);
> + if (!pdev)
> + continue;
> +
> + /*
> + * Validate against standard BARs (BAR0..BAR5) only.
> + * ROM and bridge resources are not IOA bus-error targets.
> + */
> + for (bar = 0; bar < PCI_STD_NUM_BARS; bar++) {
> + res = &pdev->resource[bar];
> +
> + if (!resource_size(res))
> + continue;
> +
> + if (!(res->flags & (IORESOURCE_MEM | IORESOURCE_IO)))
> + continue;
> +
> + pcibios_resource_to_bus(pdev->bus, ®ion, res);
[Severity: Medium]
Can validate_addr_mask_in_pe() falsely match unassigned, disabled, or
zero-initialized BARs when called via:
eeh_pe_inject_err()
-> pseries_eeh_err_inject()
-> prepare_errinjct_buffer()
-> validate_addr_mask_in_pe()
First, resource_size(res) computes res->end - res->start + 1, which
evaluates to 1 rather than 0 when res->start == 0 and res->end == 0
(unlike pci_resource_len(pdev, bar)).
Second, when a standard BAR is sized but unassigned on powerpc, such as in
pcibios_fixup_resources():
res->end -= res->start;
res->start = 0;
res->flags |= IORESOURCE_UNSET;
res->flags retains IORESOURCE_MEM or IORESOURCE_IO alongside
IORESOURCE_UNSET, with a zero-based range [0, size - 1].
When pcibios_resource_to_bus() is called on an IORESOURCE_UNSET resource:
resource_list_for_each_entry(window, &bridge->windows) {
if (resource_contains(window->res, res)) {
offset = window->offset;
break;
}
}
region->start = res->start - offset;
region->end = res->end - offset;
resource_contains() returns false because it rejects IORESOURCE_UNSET, so
window->offset is not subtracted and region.start is set to 0 with
region.end set to size - 1 (or left as the untranslated CPU resource
address if of_pci_parse_addrs() shifted res by window->offset without
zero-basing it). Any caller-supplied addr in [0, size) (including addr = 0
with a non-zero mask) will then match the unassigned BAR.
Should this check pci_resource_len(pdev, bar) and reject BARs with
IORESOURCE_UNSET | IORESOURCE_DISABLED set in res->flags, similar to
eeh_break_device()?
> +
> + bus_start = region.start;
> + bus_len = resource_size(res);
[ ... ]
> +static int validate_errinjct_args(struct eeh_pe *pe, int type, int func,
> + unsigned long addr, unsigned long mask)
> +{
> + if (!pe || !pe->phb)
> + return -EINVAL;
> +
> + if (pseries_eeh_type_to_rtas(type) < 0)
> + return -EINVAL;
> +
> + if (func < EEH_ERR_FUNC_MIN || func > EEH_ERR_FUNC_MAX)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
[ ... ]
> +static int prepare_errinjct_buffer(void *buf, struct eeh_pe *pe,
> + int rtas_err_type, int func,
> + unsigned long addr, unsigned long mask)
> +{
[Severity: Low]
Does compiling arch/powerpc/platforms/pseries/eeh_pseries.o at this commit
fail with -Werror=unused-function when CONFIG_PPC_WERROR=y or
CONFIG_WERROR=y is enabled?
Both validate_errinjct_args() and prepare_errinjct_buffer() are defined as
static without __maybe_unused, and pseries_eeh_err_inject() does not call
them until the subsequent patch in the series ("powerpc/pseries/eeh:
Implement RTAS-based EEH error injection").
The commit message notes:
"pseries_eeh_err_inject() retains the existing MMIO injection body
unchanged in this patch. It is replaced by the full RTAS session
implementation in the next patch. This keeps the patch bisectable:
each commit builds and functions correctly independently."
Should validate_errinjct_args() and prepare_errinjct_buffer() be marked
__maybe_unused in this patch (or folded into the next patch) so bisection
does not hit a build failure under -Werror?
> + __be64 *buf64 = (__be64 *)buf;
> + __be32 *buf32 = (__be32 *)buf;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261019101813.45085-1-nnmlinux@linux.ibm.com?part=2
next prev parent reply other threads:[~2026-10-19 10:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 10:18 [PATCH v5 0/5] powerpc: Add RTAS based error injection support for pSeries Narayana Murty N
2026-10-19 10:18 ` [PATCH v5 1/5] powerpc/rtas: Handle ibm,open-errinjct return format Narayana Murty N
2026-10-19 10:18 ` [PATCH v5 2/5] powerpc/pseries/eeh: Add RTAS error injection helpers Narayana Murty N
2026-10-19 10:34 ` sashiko-bot [this message]
2026-10-19 10:18 ` [PATCH v5 3/5] powerpc/pseries/eeh: Implement RTAS-based EEH error injection Narayana Murty N
2026-10-19 10:26 ` sashiko-bot
2026-10-19 10:18 ` [PATCH v5 4/5] vfio/spapr_tce: Normalize EEH IOA error injection addresses Narayana Murty N
2026-10-19 10:35 ` sashiko-bot
2026-10-19 10:18 ` [PATCH v5 5/5] powerpc/powernv/eeh: Map generic EEH error types to OPAL Narayana Murty N
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-176997@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=nnmlinux@linux.ibm.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.