Kernel KVM virtualization development
 help / color / mirror / Atom feed
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, &region, 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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox