All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yehyeong Lee" <yhlee@isslab.korea.ac.kr>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH] xen/pcifront: check that an AER callback exists before calling it
Date: Mon, 05 Oct 2026 13:40:53 +0000	[thread overview]
Message-ID: <20261005134054.394DE1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261005133019.284053-1-yhlee@isslab.korea.ac.kr>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pci: returning PCI_ERS_RESULT_NONE for missing AER callbacks kills VM
--

commit fe0aa6b512c4c3fcc950e0b0317c794634341eab
Author: Yehyeong Lee <yhlee@isslab.korea.ac.kr>

xen/pcifront: check that an AER callback exists before calling it

This commit adds NULL checks before invoking AER callbacks like mmio_enabled,
slot_reset, and resume in pcifront_common_process(). If a callback is
missing, the code now breaks out of the switch and defaults to returning
PCI_ERS_RESULT_NONE.

> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> index cffc32d660327..490913676f244 100644
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -599,12 +599,17 @@ static pci_ers_result_t pcifront_common_process(int cmd,
>  		case XEN_PCI_OP_aer_detected:
>  			return pdrv->err_handler->error_detected(pcidev, state);
>  		case XEN_PCI_OP_aer_mmio:
> -			return pdrv->err_handler->mmio_enabled(pcidev);
> +			if (pdrv->err_handler->mmio_enabled)
> +				return pdrv->err_handler->mmio_enabled(pcidev);
> +			break;
>  		case XEN_PCI_OP_aer_slotreset:
> -			return pdrv->err_handler->slot_reset(pcidev);
> +			if (pdrv->err_handler->slot_reset)
> +				return pdrv->err_handler->slot_reset(pcidev);
> +			break;

[Severity: High]
Does breaking out of the switch here when a callback is missing cause the
guest VM to be forcefully terminated by the host backend?

If the code breaks out of the switch, pcifront_common_process() falls
through and returns PCI_ERS_RESULT_NONE.

In the host backend, functions like xen_pcibk_mmio_enabled() and
xen_pcibk_slot_reset() strictly treat PCI_ERS_RESULT_NONE as a fatal
condition:

drivers/xen/xen-pciback/pci_stub.c:xen_pcibk_mmio_enabled() {
    ...
    if (result == PCI_ERS_RESULT_NONE ||
        result == PCI_ERS_RESULT_DISCONNECT) {
        dev_dbg(&dev->dev,
            "No AER mmio_enabled service or disconnected!\n");
        kill_domain_by_device(psdev);
    }
    ...
}

The standard PCI core defaults to PCI_ERS_RESULT_RECOVERED when these
callbacks are missing. Could xen-pcifront return a success status to allow
recovery to proceed, rather than returning PCI_ERS_RESULT_NONE which leads
to killing the domain?

While this patch replaces a guest NULL pointer dereference with a
host-initiated VM kill, changing the mechanism, it appears to fail to fix
the underlying guest death.

>  		case XEN_PCI_OP_aer_resume:
> -			pdrv->err_handler->resume(pcidev);
> -			return PCI_ERS_RESULT_NONE;
> +			if (pdrv->err_handler->resume)
> +				pdrv->err_handler->resume(pcidev);
> +			break;
>  		default:
>  			dev_err(&pdev->xdev->dev,
>  				"bad request in aer recovery operation!\n");

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005133019.284053-1-yhlee@isslab.korea.ac.kr?part=1

  reply	other threads:[~2026-10-05 13:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-05 13:30 [PATCH] xen/pcifront: check that an AER callback exists before calling it Yehyeong Lee
2026-10-05 13:40 ` sashiko-bot [this message]
2026-10-05 19:05 ` Bjorn Helgaas

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=20261005134054.394DE1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yhlee@isslab.korea.ac.kr \
    /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.