From: sashiko-bot@kernel.org
To: "Anthony Krowiak" <akrowiak@linux.ibm.com>
Cc: linux-s390@vger.kernel.org,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
kvm@vger.kernel.org,
"Christian Borntraeger" <borntraeger@linux.ibm.vom>,
"Vasily Gorbik" <gor@linux.ibm.com>
Subject: Re: [PATCH v5 9/9] s390/vfio-ap: Fix memory leak when queue removed from host AP config
Date: Wed, 12 Aug 2026 20:35:20 +0000 [thread overview]
Message-ID: <20260812203520.C906C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260812200240.818004-10-akrowiak@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incomplete fix for resource leak: `vfio_ap_mdev_reset_queue()` does not handle `AP_RESPONSE_Q_NOT_AVAIL` (0x01), causing KVM GISC/pinned memory leaks and spurious WARN_ON stack traces.
--
--- Patch [9]: [PATCH v5 9/9] s390/vfio-ap: Fix memory leak when queue removed from host AP config ---
commit 6c8828db27ae24e9b17bf29e492fb4382c470413
Author: Anthony Krowiak <akrowiak@linux.ibm.com>
s390/vfio-ap: Fix memory leak when queue removed from host AP config
This patch aims to fix a memory leak of KVM GISC resources and pinned guest
memory when an adapter or domain is removed from the host's AP configuration.
It bypasses the queue reset and directly frees the AQIC resources if the
queue is no longer in the host config.
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> index 1edd0b7a3cce7..bd9d239caeba2 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -2533,12 +2533,15 @@ void vfio_ap_mdev_remove_queue(struct ap_device *apdev)
> /*
> * If the queue is not in the host's AP configuration, then resetting
> * it will fail with response code 01, (APQN not valid); so, let's make
> - * sure it is in the host's config.
> + * sure it is in the host's config. If it is not, then free the KVM GISC
> + * resources.
> */
> if (test_bit_inv(apid, (unsigned long *)matrix_dev->info.apm) &&
> test_bit_inv(apqi, (unsigned long *)matrix_dev->info.aqm)) {
> vfio_ap_mdev_reset_queue(q);
> flush_work(&q->reset_work);
> + } else {
> + vfio_ap_free_aqic_resources(q);
[Severity: High]
Can this still trigger a WARN_ON and leak KVM GISC and pinned memory if a guest
shuts down or the mdev is removed before the physical queue is unbound?
When an adapter is removed from the host config, ap_zapq() returns 0x01
(AP_RESPONSE_Q_NOT_AVAIL). If vfio_ap_mdev_reset_queue() receives this response
(for example, during guest shutdown), it falls into the default case, logs a
WARN, and skips freeing AQIC resources:
drivers/s390/crypto/vfio_ap_ops.c:vfio_ap_mdev_reset_queue() {
...
default:
WARN(true,
"PQAP/ZAPQ for %02x.%04x failed with invalid rc=%u\n",
AP_QID_CARD(q->apqn), AP_QID_QUEUE(q->apqn),
status.response_code);
...
}
The driver might then clear the kvm or q->matrix_mdev pointers. Later, when
the physical queue is unbound and this else branch is reached,
vfio_ap_free_aqic_resources(q) would hit the WARN_ON checks because the
pointers are now NULL:
drivers/s390/crypto/vfio_ap_ops.c:vfio_ap_free_aqic_resources() {
...
if (q->saved_isc != VFIO_AP_ISC_INVALID &&
!WARN_ON(!(q->matrix_mdev && q->matrix_mdev->kvm))) {
...
if (q->saved_iova && !WARN_ON(!q->matrix_mdev)) {
...
}
Should vfio_ap_mdev_reset_queue() be updated to explicitly handle response
code 0x01 and clean up resources there as well to ensure they are freed
before the pointers are cleared?
> }
>
> done:
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260812200240.818004-1-akrowiak@linux.ibm.com?part=9
next prev parent reply other threads:[~2026-08-12 20:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 20:02 [PATCH v5 0/9] s390/vfio-ap: Fix bugs in vfio_ap device driver callback functions Anthony Krowiak
2026-08-12 20:02 ` [PATCH v5 1/9] s390/vfio-ap: Fix stale do_remove flag across iterations in vfio_ap_mdev_cfg_remove Anthony Krowiak
2026-08-12 20:20 ` sashiko-bot
2026-08-12 20:02 ` [PATCH v5 2/9] s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL Anthony Krowiak
2026-08-12 20:17 ` sashiko-bot
2026-08-12 20:02 ` [PATCH v5 3/9] s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects Anthony Krowiak
2026-08-12 20:23 ` sashiko-bot
2026-08-12 20:02 ` [PATCH v5 4/9] s390/vfio-ap: Fix required lock not held during update of ap_matrix_mdev object Anthony Krowiak
2026-08-12 20:18 ` sashiko-bot
2026-08-12 20:02 ` [PATCH v5 5/9] s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove Anthony Krowiak
2026-08-12 20:16 ` sashiko-bot
2026-08-12 20:02 ` [PATCH v5 6/9] s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap Anthony Krowiak
2026-08-12 20:20 ` sashiko-bot
2026-08-12 20:02 ` [PATCH v5 7/9] s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain removed Anthony Krowiak
2026-08-12 20:09 ` sashiko-bot
2026-08-12 20:02 ` [PATCH v5 8/9] s390/vfio-ap: Fix NULL deref in status_show() during queue probe Anthony Krowiak
2026-08-12 20:22 ` sashiko-bot
2026-08-12 20:54 ` Matthew Rosato
2026-08-12 20:02 ` [PATCH v5 9/9] s390/vfio-ap: Fix memory leak when queue removed from host AP config Anthony Krowiak
2026-08-12 20:35 ` sashiko-bot [this message]
2026-08-12 21:12 ` Matthew Rosato
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=20260812203520.C906C1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=akrowiak@linux.ibm.com \
--cc=borntraeger@linux.ibm.vom \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--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