Linux s390 Architecture development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Anthony Krowiak" <akrowiak@linux.ibm.com>
Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Heiko Carstens" <hca@linux.ibm.com>
Subject: Re: [PATCH 5/5] s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove
Date: Sat, 08 Aug 2026 17:30:21 +0000	[thread overview]
Message-ID: <20260808173022.0208E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260808170712.839066-6-akrowiak@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Missing KVM guest configuration updates when the last AP device or domain is unplugged due to incorrect usage of `bitmap_andnot` return value.
--

--- Patch [5]: [PATCH 5/5] s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove ---
commit c11c3bac302d3bc1f0a23db222df493383b0819f
Author: Anthony Krowiak <akrowiak@linux.ibm.com>

s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove

The vfio_ap_config_remove function uses the bitmap_andnot function to clear
bits from the matrix_mdev->matrix.adm bitmap (specifies the control domains
assigned to the mdev). This prevents the explicitly unplugged control
domains from being removed the KVM guest. The bitmap_and function is used
instead.

> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> index 897518b88c281..9c7257c179a7a 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -2621,9 +2621,9 @@ static void vfio_ap_mdev_cfg_remove(unsigned long *ap_remove,
>  		do_remove |= bitmap_and(aqrem, aq_remove,
>  					  matrix_mdev->matrix.aqm,
>  					  AP_DOMAINS);
> -		do_remove |= bitmap_andnot(cdrem, cd_remove,
> -					     matrix_mdev->matrix.adm,
> -					     AP_DOMAINS);
> +		do_remove |= bitmap_and(cdrem, cd_remove,
> +					matrix_mdev->matrix.adm,
> +					AP_DOMAINS);
>  
>  		if (do_remove)
>  			vfio_ap_mdev_hot_unplug_cfg(matrix_mdev, aprem, aqrem,

[Severity: Critical]
This is a pre-existing issue, but does the bitwise logic in
vfio_ap_mdev_hot_unplug_cfg() incorrectly assume bitmap_andnot() returns true
when bits are cleared?

Looking at vfio_ap_mdev_hot_unplug_cfg(), the return value of bitmap_andnot()
is used to determine if a hotplug update is necessary:

drivers/s390/crypto/vfio_ap_ops.c:vfio_ap_mdev_hot_unplug_cfg() {
	...
	if (!bitmap_empty(aprem, AP_DEVICES)) {
		do_hotplug |= bitmap_andnot(matrix_mdev->shadow_apcb.apm,
					    matrix_mdev->shadow_apcb.apm,
					    aprem, AP_DEVICES);
	}
	...
	if (do_hotplug)
		vfio_ap_mdev_update_guest_apcb(matrix_mdev);
}

However, bitmap_andnot() returns false when the resulting destination bitmap
becomes empty.

If a host administrator unplugs the final active AP adapter or domain assigned
to an mdev, the unplugged bit is cleared from the guest mask, leaving the
shadow_apcb bitmap entirely empty. Because it is empty, bitmap_andnot()
returns false.

Will this cause do_hotplug to evaluate to 0 and skip calling
vfio_ap_mdev_update_guest_apcb() entirely, allowing the KVM guest to retain
hardware access to unplugged or revoked AP devices? The same pattern is used
for aqm and adm on subsequent lines.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260808170712.839066-1-akrowiak@linux.ibm.com?part=5

  reply	other threads:[~2026-08-08 17:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-08 17:07 [PATCH 0/5] s390/vfio-ap: Fix bugs in vfio_ap device driver callback functions Anthony Krowiak
2026-08-08 17:07 ` [PATCH 1/5] s390/vfio-ap: Fix stale do_remove flag across iterations in vfio_ap_mdev_cfg_remove Anthony Krowiak
2026-08-08 17:49   ` sashiko-bot
2026-08-10 14:01     ` Anthony Krowiak
2026-08-10 19:03       ` Anthony Krowiak
2026-08-08 17:07 ` [PATCH 2/5] s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL Anthony Krowiak
2026-08-08 17:36   ` sashiko-bot
2026-08-10 14:37     ` Anthony Krowiak
2026-08-08 17:07 ` [PATCH 3/5] s390/vfio-ap: Fix use of wrong lock in mdev probe function Anthony Krowiak
2026-08-08 17:32   ` sashiko-bot
2026-08-08 17:07 ` [PATCH 4/5] s390/vfio-ap: Fix required lock not held during update of ap_matrix_mdev object Anthony Krowiak
2026-08-08 17:34   ` sashiko-bot
2026-08-08 17:07 ` [PATCH 5/5] s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove Anthony Krowiak
2026-08-08 17:30   ` sashiko-bot [this message]
2026-08-10 18:02     ` Anthony Krowiak

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=20260808173022.0208E1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=akrowiak@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=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