From: sashiko-bot@kernel.org
To: "Omar Elghoul" <oelghoul@linux.ibm.com>
Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>
Subject: Re: [PATCH v4 2/4] s390/pci: Preserve FMB state in device re-enablement
Date: Fri, 12 Jun 2026 18:26:31 +0000 [thread overview]
Message-ID: <20260612182632.E4EE71F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260612181048.91548-3-oelghoul@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] zpci_fmb_reenable_device() reuses the existing FMB hardware buffer without zeroing it, exposing stale hardware counter values until the first periodic hardware update occurs.
--
commit a81b1b0a067d09df54d661ddbb8985e9220d9a88
Author: Omar Elghoul <oelghoul@linux.ibm.com>
s390/pci: Preserve FMB state in device re-enablement
This commit introduces zpci_fmb_reenable_device() to reuse the existing FMB
buffer during device re-enablement instead of allocating a new one. It also
refactors the FMB enablement and software counter clearing logic into shared
helpers.
> diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
> index 2910d4038d39c..21d3fccac7894 100644
> --- a/arch/s390/pci/pci.c
> +++ b/arch/s390/pci/pci.c
[ ... ]
> +int zpci_fmb_reenable_device(struct zpci_dev *zdev)
> +{
> + u64 req = ZPCI_CREATE_REQ(zdev->fh, 0, ZPCI_MOD_FC_SET_MEASURE);
> + struct zpci_fib fib = {0};
> + u8 cc, status;
> + int rc;
> +
> + lockdep_assert_held(&zdev->fmb_lock);
> +
> + if (!zdev->fmb)
> + return zpci_fmb_enable_device(zdev);
> +
> + fib.gd = zdev->gisa;
> + cc = zpci_mod_fc(req, &fib, &status); /* Disable function measurement */
> +
> + /* Unlike in zpci_fmb_disable_device(), cc == 3 is not a valid state here
> + * because we are re-enabling function measurement for the same function
> + * handle.
> + */
> + if (cc)
> + return -EIO;
> +
> + zpci_fmb_clear_iommu_ctrs(zdev);
> +
[Severity: Medium]
Does this code need to zero the reused zdev->fmb buffer before enabling it?
The commit message states that a program resetting an FMB should see all
counters start from zero. While zpci_fmb_clear_iommu_ctrs() clears the
software-maintained IOMMU counters, the hardware-maintained FMB buffer
(zdev->fmb) is reused here without being cleared.
Could this expose stale hardware counter values to userspace until the
first asynchronous hardware update occurs? The previous behavior in
zpci_fmb_enable_device() allocated a fresh, zero-initialized buffer via
kmem_cache_zalloc().
> + rc = zpci_fmb_do_enable(zdev);
> + if (rc) {
> + kmem_cache_free(zdev_fmb_cache, zdev->fmb);
> + zdev->fmb = NULL;
> + }
> +
> + return rc;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612181048.91548-1-oelghoul@linux.ibm.com?part=2
next prev parent reply other threads:[~2026-06-12 18:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-12 18:10 [PATCH v4 0/4] vfio-pci/zdev: Improved zPCI Function Measurement Support Omar Elghoul
2026-06-12 18:10 ` [PATCH v4 1/4] s390/pci: Hold fmb_lock when enabling or disabling PCI devices Omar Elghoul
2026-06-12 18:28 ` sashiko-bot
2026-06-12 18:10 ` [PATCH v4 2/4] s390/pci: Preserve FMB state in device re-enablement Omar Elghoul
2026-06-12 18:26 ` sashiko-bot [this message]
2026-06-12 18:10 ` [PATCH v4 3/4] vfio-pci/zdev: Add VFIO FMB device features Omar Elghoul
2026-06-12 18:28 ` sashiko-bot
2026-06-12 18:10 ` [PATCH v4 4/4] s390/pci: Fence FMB enable/disable via sysfs for passthrough devices Omar Elghoul
2026-06-12 18:22 ` 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=20260612182632.E4EE71F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=oelghoul@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.