From: Alex Williamson <alex@shazbot.org>
To: Farhan Ali <alifm@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, helgaas@kernel.org, lukas@wunner.de,
clg@redhat.com, kbusch@kernel.org, schnelle@linux.ibm.com,
mjrosato@linux.ibm.com, alex@shazbot.org
Subject: Re: [PATCH v12 4/7] s390/pci: Store PCI error information for passthrough devices
Date: Tue, 7 Apr 2026 12:23:39 -0600 [thread overview]
Message-ID: <20260407122339.10846181@shazbot.org> (raw)
In-Reply-To: <5d8ba477-9a4c-4bac-b36f-a5c33de57850@linux.ibm.com>
On Tue, 7 Apr 2026 11:00:05 -0700
Farhan Ali <alifm@linux.ibm.com> wrote:
> On 4/7/2026 8:38 AM, Alex Williamson wrote:
> > On Mon, 30 Mar 2026 10:40:08 -0700
> > Farhan Ali <alifm@linux.ibm.com> wrote:
> >> @@ -194,13 +214,6 @@ static pci_ers_result_t zpci_event_attempt_error_recovery(struct pci_dev *pdev)
> >> }
> >> pdev->error_state = pci_channel_io_frozen;
> >>
> >> - if (is_passed_through(pdev)) {
> >> - pr_info("%s: Cannot be recovered in the host because it is a pass-through device\n",
> >> - pci_name(pdev));
> >> - status_str = "failed (pass-through)";
> >> - goto out_unlock;
> >> - }
> >> -
> >> driver = to_pci_driver(pdev->dev.driver);
> >> if (!is_driver_supported(driver)) {
> >> if (!driver) {
> >> @@ -216,12 +229,23 @@ static pci_ers_result_t zpci_event_attempt_error_recovery(struct pci_dev *pdev)
> >> goto out_unlock;
> >> }
> >>
> >> + if (needs_mediated_recovery(pdev))
> > The test result is invalid here. Why not call zpci_store_pci_error()
> > unconditionally here and wrap both in the same guard?
> > needs_mediated_recovery() should have a lockdep_assert.
>
> I think storing the error via zpci_store_pci_error() only made sense if
> the error needed to be handled outside the kernel. Thinking more now I
> think it makes sense to have separate locks, as the mediated_recovery
> flag really provides information on if the vfio device is still opened
> or closed.
I don't think separate locks help the situation, the might conflate it
further. I think the problem here is that we're using the lock as if
it protects two separate things, the mediated_recovery flag vs the
pending_errs structure, but in fact they're related. We only record
errors to the structure when we're in mediated_recovery and we clear
the structure when exiting mediated recovery. One lock makes sense to
me, but it needs to protect both the state of the flag and the use of
the structure together, not independently. Thanks,
Alex
next prev parent reply other threads:[~2026-04-07 18:23 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 17:40 [PATCH v12 0/7] Error recovery for vfio-pci devices on s390x Farhan Ali
2026-03-30 17:40 ` [PATCH v12 1/7] PCI: Allow per function PCI slots to fix slot reset on s390 Farhan Ali
2026-03-30 17:40 ` [PATCH v12 2/7] PCI: Avoid saving config space state if inaccessible Farhan Ali
2026-04-07 19:56 ` Bjorn Helgaas
2026-04-07 21:17 ` Farhan Ali
2026-04-07 21:32 ` Bjorn Helgaas
2026-04-07 22:02 ` Farhan Ali
2026-03-30 17:40 ` [PATCH v12 3/7] PCI: Fail FLR when config space is inaccessible Farhan Ali
2026-03-30 17:40 ` [PATCH v12 4/7] s390/pci: Store PCI error information for passthrough devices Farhan Ali
2026-03-31 17:41 ` Matthew Rosato
2026-03-31 19:23 ` Farhan Ali
2026-03-31 19:29 ` Matthew Rosato
2026-04-07 15:38 ` Alex Williamson
2026-04-07 18:00 ` Farhan Ali
2026-04-07 18:23 ` Alex Williamson [this message]
2026-03-30 17:40 ` [PATCH v12 5/7] vfio-pci/zdev: Add a device feature for error information Farhan Ali
2026-03-31 17:42 ` Matthew Rosato
2026-03-31 19:27 ` Farhan Ali
2026-04-07 15:53 ` Alex Williamson
2026-04-07 18:13 ` Farhan Ali
2026-04-07 18:27 ` Alex Williamson
2026-03-30 17:40 ` [PATCH v12 6/7] vfio/pci: Add a reset_done callback for vfio-pci driver Farhan Ali
2026-03-31 17:43 ` Matthew Rosato
2026-03-30 17:40 ` [PATCH v12 7/7] vfio/pci: Remove the pcie check for VFIO_PCI_ERR_IRQ_INDEX Farhan Ali
2026-04-07 15:58 ` Alex Williamson
2026-04-06 17:23 ` [PATCH v12 0/7] Error recovery for vfio-pci devices on s390x Farhan Ali
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=20260407122339.10846181@shazbot.org \
--to=alex@shazbot.org \
--cc=alifm@linux.ibm.com \
--cc=clg@redhat.com \
--cc=helgaas@kernel.org \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mjrosato@linux.ibm.com \
--cc=schnelle@linux.ibm.com \
/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