[PATCH 1/4] s390/vfio-ap: Fix leak of pinned NIB and registered NISC in vfio_ap_irq_enable()

[PATCH 1/4] s390/vfio-ap: Fix leak of pinned NIB and registered NISC in vfio_ap_irq_enable()

[Anthony Krowiak]

The vfio_ap_irq_enable() function executes the PQAP(AQIC) instruction to
enable interrupts for an AP queue. A switch statement is used to examine
the status response code returned from the instruction to determine
whether it succeeded or failed and react accordingly. For the default case,
the vfio_ap_irq_disable function is invoked to disable interrupts for the
queue and clean up the AQIC resources (i.e., unpin the NIB and unregister
the NISC). There are a number of problems with this:

1. Neither the q->saved_iova nor q->saved_isc has been set, so the
   AQIC resources - assuming those values have been previously set - will
   be the NIB and NISC resources from a prior call; the NIB and NISC from
   the current call are therefore leaked.

2. Interrupts may never have been enabled. Sending a disable instruction to
   a queue that the hardware just told you is in a bad state (CHECKSTOPPED,
   DECONFIGURED, Q_NOT_AVAIL) is at best wasted work and at worst generates
   a further WARN_ONCE from inside vfio_ap_irq_disable's own default.

3. The hardware just rejected the new ap_aqic() enable attempt with an
   unexpected status. Disabling a previously-working IRQ config - assuming
   that is even possible - as a reaction to a failed enable attempt does
   not make sense; it is actively destructive, tearing down something that
   was working for no valid reason.

The fix is to unregister the NISC and an unpin the NIB in the default case
of the switch statement.

Fixes: ec89b55e3bce7 ("s390: ap: implement PAPQ AQIC interception in kernel")
Cc: stable@vger.kernel.org
Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
---
 drivers/s390/crypto/vfio_ap_ops.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
index 940c0ff668be..a46bf381ab72 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -503,9 +503,14 @@ static struct ap_queue_status vfio_ap_irq_enable(struct vfio_ap_queue *q,
 		vfio_unpin_pages(&q->matrix_mdev->vdev, nib, 1);
 		break;
 	default:
-		pr_warn("%s: apqn %04x: response: %02x\n", __func__, q->apqn,
-			status.response_code);
-		vfio_ap_irq_disable(q);
+		pr_warn("%s: PQAP(AQIC) failed with response code %02x for apqn %04x\n",
+			__func__, status.response_code, q->apqn);
+		/* We could not modify IRQ settings: clear new configuration */
+		ret = kvm_s390_gisc_unregister(kvm, isc);
+		if (ret)
+			VFIO_AP_DBF_WARN("%s: kvm_s390_gisc_unregister: rc=%d isc=%d, apqn=%#04x\n",
+					 __func__, ret, isc, q->apqn);
+		vfio_unpin_pages(&q->matrix_mdev->vdev, nib, 1);
 		break;
 	}
 
-- 
2.53.0

Re: [PATCH 1/4] s390/vfio-ap: Fix leak of pinned NIB and registered NISC in vfio_ap_irq_enable()

[Matthew Rosato]

On 8/24/26 9:58 AM, Anthony Krowiak wrote:
> The vfio_ap_irq_enable() function executes the PQAP(AQIC) instruction to
> enable interrupts for an AP queue. A switch statement is used to examine
> the status response code returned from the instruction to determine
> whether it succeeded or failed and react accordingly. For the default case,
> the vfio_ap_irq_disable function is invoked to disable interrupts for the
> queue and clean up the AQIC resources (i.e., unpin the NIB and unregister
> the NISC). There are a number of problems with this:
> 
> 1. Neither the q->saved_iova nor q->saved_isc has been set, so the
>    AQIC resources - assuming those values have been previously set - will
>    be the NIB and NISC resources from a prior call; the NIB and NISC from
>    the current call are therefore leaked.
> 
> 2. Interrupts may never have been enabled. Sending a disable instruction to
>    a queue that the hardware just told you is in a bad state (CHECKSTOPPED,
>    DECONFIGURED, Q_NOT_AVAIL) is at best wasted work and at worst generates
>    a further WARN_ONCE from inside vfio_ap_irq_disable's own default.
> 
> 3. The hardware just rejected the new ap_aqic() enable attempt with an
>    unexpected status. Disabling a previously-working IRQ config - assuming
>    that is even possible - as a reaction to a failed enable attempt does
>    not make sense; it is actively destructive, tearing down something that
>    was working for no valid reason.
> 
> The fix is to unregister the NISC and an unpin the NIB in the default case
> of the switch statement.
> 
> Fixes: ec89b55e3bce7 ("s390: ap: implement PAPQ AQIC interception in kernel")
> Cc: stable@vger.kernel.org
> Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
> ---
>  drivers/s390/crypto/vfio_ap_ops.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> index 940c0ff668be..a46bf381ab72 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -503,9 +503,14 @@ static struct ap_queue_status vfio_ap_irq_enable(struct vfio_ap_queue *q,
>  		vfio_unpin_pages(&q->matrix_mdev->vdev, nib, 1);
>  		break;
>  	default:
> -		pr_warn("%s: apqn %04x: response: %02x\n", __func__, q->apqn,
> -			status.response_code);
> -		vfio_ap_irq_disable(q);
> +		pr_warn("%s: PQAP(AQIC) failed with response code %02x for apqn %04x\n",
> +			__func__, status.response_code, q->apqn);

LGTM, except Sashiko mentions the pr_warn here that you are updating has
a pre-existing issue.

Since you're touching it already, do you think it makes sense to switch
to pr_warn_ratelimited with this patch?

> +		/* We could not modify IRQ settings: clear new configuration */
> +		ret = kvm_s390_gisc_unregister(kvm, isc);
> +		if (ret)
> +			VFIO_AP_DBF_WARN("%s: kvm_s390_gisc_unregister: rc=%d isc=%d, apqn=%#04x\n",
> +					 __func__, ret, isc, q->apqn);
> +		vfio_unpin_pages(&q->matrix_mdev->vdev, nib, 1);
>  		break;
>  	}
>  

Re: [PATCH 1/4] s390/vfio-ap: Fix leak of pinned NIB and registered NISC in vfio_ap_irq_enable()

[Anthony Krowiak]

On 8/24/26 12:57 PM, Matthew Rosato wrote:
> On 8/24/26 9:58 AM, Anthony Krowiak wrote:
>> The vfio_ap_irq_enable() function executes the PQAP(AQIC) instruction to
>> enable interrupts for an AP queue. A switch statement is used to examine
>> the status response code returned from the instruction to determine
>> whether it succeeded or failed and react accordingly. For the default case,
>> the vfio_ap_irq_disable function is invoked to disable interrupts for the
>> queue and clean up the AQIC resources (i.e., unpin the NIB and unregister
>> the NISC). There are a number of problems with this:
>>
>> 1. Neither the q->saved_iova nor q->saved_isc has been set, so the
>>     AQIC resources - assuming those values have been previously set - will
>>     be the NIB and NISC resources from a prior call; the NIB and NISC from
>>     the current call are therefore leaked.
>>
>> 2. Interrupts may never have been enabled. Sending a disable instruction to
>>     a queue that the hardware just told you is in a bad state (CHECKSTOPPED,
>>     DECONFIGURED, Q_NOT_AVAIL) is at best wasted work and at worst generates
>>     a further WARN_ONCE from inside vfio_ap_irq_disable's own default.
>>
>> 3. The hardware just rejected the new ap_aqic() enable attempt with an
>>     unexpected status. Disabling a previously-working IRQ config - assuming
>>     that is even possible - as a reaction to a failed enable attempt does
>>     not make sense; it is actively destructive, tearing down something that
>>     was working for no valid reason.
>>
>> The fix is to unregister the NISC and an unpin the NIB in the default case
>> of the switch statement.
>>
>> Fixes: ec89b55e3bce7 ("s390: ap: implement PAPQ AQIC interception in kernel")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
>> ---
>>   drivers/s390/crypto/vfio_ap_ops.c | 11 ++++++++---
>>   1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
>> index 940c0ff668be..a46bf381ab72 100644
>> --- a/drivers/s390/crypto/vfio_ap_ops.c
>> +++ b/drivers/s390/crypto/vfio_ap_ops.c
>> @@ -503,9 +503,14 @@ static struct ap_queue_status vfio_ap_irq_enable(struct vfio_ap_queue *q,
>>   		vfio_unpin_pages(&q->matrix_mdev->vdev, nib, 1);
>>   		break;
>>   	default:
>> -		pr_warn("%s: apqn %04x: response: %02x\n", __func__, q->apqn,
>> -			status.response_code);
>> -		vfio_ap_irq_disable(q);
>> +		pr_warn("%s: PQAP(AQIC) failed with response code %02x for apqn %04x\n",
>> +			__func__, status.response_code, q->apqn);
> LGTM, except Sashiko mentions the pr_warn here that you are updating has
> a pre-existing issue.
>
> Since you're touching it already, do you think it makes sense to switch
> to pr_warn_ratelimited with this patch?

I think it makes more sense to switch to VFIO_AP_DBF_WARN which all other
guest-triggered warning paths in  this function already use.

>
>> +		/* We could not modify IRQ settings: clear new configuration */
>> +		ret = kvm_s390_gisc_unregister(kvm, isc);
>> +		if (ret)
>> +			VFIO_AP_DBF_WARN("%s: kvm_s390_gisc_unregister: rc=%d isc=%d, apqn=%#04x\n",
>> +					 __func__, ret, isc, q->apqn);
>> +		vfio_unpin_pages(&q->matrix_mdev->vdev, nib, 1);
>>   		break;
>>   	}
>>   

Re: [PATCH 1/4] s390/vfio-ap: Fix leak of pinned NIB and registered NISC in vfio_ap_irq_enable()

[Anthony Krowiak]

On 8/24/26 12:57 PM, Matthew Rosato wrote:
> On 8/24/26 9:58 AM, Anthony Krowiak wrote:
>> The vfio_ap_irq_enable() function executes the PQAP(AQIC) instruction to
>> enable interrupts for an AP queue. A switch statement is used to examine
>> the status response code returned from the instruction to determine
>> whether it succeeded or failed and react accordingly. For the default case,
>> the vfio_ap_irq_disable function is invoked to disable interrupts for the
>> queue and clean up the AQIC resources (i.e., unpin the NIB and unregister
>> the NISC). There are a number of problems with this:
>>
>> 1. Neither the q->saved_iova nor q->saved_isc has been set, so the
>>     AQIC resources - assuming those values have been previously set - will
>>     be the NIB and NISC resources from a prior call; the NIB and NISC from
>>     the current call are therefore leaked.
>>
>> 2. Interrupts may never have been enabled. Sending a disable instruction to
>>     a queue that the hardware just told you is in a bad state (CHECKSTOPPED,
>>     DECONFIGURED, Q_NOT_AVAIL) is at best wasted work and at worst generates
>>     a further WARN_ONCE from inside vfio_ap_irq_disable's own default.
>>
>> 3. The hardware just rejected the new ap_aqic() enable attempt with an
>>     unexpected status. Disabling a previously-working IRQ config - assuming
>>     that is even possible - as a reaction to a failed enable attempt does
>>     not make sense; it is actively destructive, tearing down something that
>>     was working for no valid reason.
>>
>> The fix is to unregister the NISC and an unpin the NIB in the default case
>> of the switch statement.
>>
>> Fixes: ec89b55e3bce7 ("s390: ap: implement PAPQ AQIC interception in kernel")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
>> ---
>>   drivers/s390/crypto/vfio_ap_ops.c | 11 ++++++++---
>>   1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
>> index 940c0ff668be..a46bf381ab72 100644
>> --- a/drivers/s390/crypto/vfio_ap_ops.c
>> +++ b/drivers/s390/crypto/vfio_ap_ops.c
>> @@ -503,9 +503,14 @@ static struct ap_queue_status vfio_ap_irq_enable(struct vfio_ap_queue *q,
>>   		vfio_unpin_pages(&q->matrix_mdev->vdev, nib, 1);
>>   		break;
>>   	default:
>> -		pr_warn("%s: apqn %04x: response: %02x\n", __func__, q->apqn,
>> -			status.response_code);
>> -		vfio_ap_irq_disable(q);
>> +		pr_warn("%s: PQAP(AQIC) failed with response code %02x for apqn %04x\n",
>> +			__func__, status.response_code, q->apqn);
> LGTM, except Sashiko mentions the pr_warn here that you are updating has
> a pre-existing issue.
>
> Since you're touching it already, do you think it makes sense to switch
> to pr_warn_ratelimited with this patch?

Since this is a pre-existing problem not introduced with this patch and 
there is
likewise another related problem not introduced by this patch, I am 
going to
post a separated series with fixes to those two related issues.

>
>> +		/* We could not modify IRQ settings: clear new configuration */
>> +		ret = kvm_s390_gisc_unregister(kvm, isc);
>> +		if (ret)
>> +			VFIO_AP_DBF_WARN("%s: kvm_s390_gisc_unregister: rc=%d isc=%d, apqn=%#04x\n",
>> +					 __func__, ret, isc, q->apqn);
>> +		vfio_unpin_pages(&q->matrix_mdev->vdev, nib, 1);
>>   		break;
>>   	}
>>   

Re: [PATCH 1/4] s390/vfio-ap: Fix leak of pinned NIB and registered NISC in vfio_ap_irq_enable()

[Matthew Rosato]

>>> -        pr_warn("%s: apqn %04x: response: %02x\n", __func__, q->apqn,
>>> -            status.response_code);
>>> -        vfio_ap_irq_disable(q);
>>> +        pr_warn("%s: PQAP(AQIC) failed with response code %02x for
>>> apqn %04x\n",
>>> +            __func__, status.response_code, q->apqn);
>> LGTM, except Sashiko mentions the pr_warn here that you are updating has
>> a pre-existing issue.
>>
>> Since you're touching it already, do you think it makes sense to switch
>> to pr_warn_ratelimited with this patch?
> 
> Since this is a pre-existing problem not introduced with this patch and
> there is
> likewise another related problem not introduced by this patch, I am
> going to
> post a separated series with fixes to those two related issues.
> 
Isn't the change in pr_warn wording here also unnecessary/cosmetic?

Why don't you remove the change to pr_warn from this patch and re-word
it at the same time you convert it to VFIO_AP_DBF_WARN -- that way you
avoid touching/extending the pre-existing issue with this patch.

Re: [PATCH 1/4] s390/vfio-ap: Fix leak of pinned NIB and registered NISC in vfio_ap_irq_enable()

[Anthony Krowiak]

On 8/24/26 3:56 PM, Matthew Rosato wrote:
>>>> -        pr_warn("%s: apqn %04x: response: %02x\n", __func__, q->apqn,
>>>> -            status.response_code);
>>>> -        vfio_ap_irq_disable(q);
>>>> +        pr_warn("%s: PQAP(AQIC) failed with response code %02x for
>>>> apqn %04x\n",
>>>> +            __func__, status.response_code, q->apqn);
>>> LGTM, except Sashiko mentions the pr_warn here that you are updating has
>>> a pre-existing issue.
>>>
>>> Since you're touching it already, do you think it makes sense to switch
>>> to pr_warn_ratelimited with this patch?
>> Since this is a pre-existing problem not introduced with this patch and
>> there is
>> likewise another related problem not introduced by this patch, I am
>> going to
>> post a separated series with fixes to those two related issues.
>>
> Isn't the change in pr_warn wording here also unnecessary/cosmetic?
>
> Why don't you remove the change to pr_warn from this patch and re-word
> it at the same time you convert it to VFIO_AP_DBF_WARN -- that way you
> avoid touching/extending the pre-existing issue with this patch.

Sure, will do.

Re: [PATCH 1/4] s390/vfio-ap: Fix leak of pinned NIB and registered NISC in vfio_ap_irq_enable()

[Anthony Krowiak]

On 8/24/26 3:56 PM, Matthew Rosato wrote:
>>>> -        pr_warn("%s: apqn %04x: response: %02x\n", __func__, q->apqn,
>>>> -            status.response_code);
>>>> -        vfio_ap_irq_disable(q);
>>>> +        pr_warn("%s: PQAP(AQIC) failed with response code %02x for
>>>> apqn %04x\n",
>>>> +            __func__, status.response_code, q->apqn);
>>> LGTM, except Sashiko mentions the pr_warn here that you are updating has
>>> a pre-existing issue.
>>>
>>> Since you're touching it already, do you think it makes sense to switch
>>> to pr_warn_ratelimited with this patch?
>> Since this is a pre-existing problem not introduced with this patch and
>> there is
>> likewise another related problem not introduced by this patch, I am
>> going to
>> post a separated series with fixes to those two related issues.
>>
> Isn't the change in pr_warn wording here also unnecessary/cosmetic?
>
> Why don't you remove the change to pr_warn from this patch and re-word
> it at the same time you convert it to VFIO_AP_DBF_WARN -- that way you
> avoid touching/extending the pre-existing issue with this patch.

Actually, now that I've looked at the entirety of the code, there is no
need to add a VFIO_AP_DBF_WARN here. After the switch statement
we have the following which duplicates the pr_warn but with more
detail:

if(status.response_code!= AP_RESPONSE_NORMAL) { VFIO_AP_DBF_WARN("%s: 
PQAP(AQIC) failed with status=%#02x: " "zone=%#x, ir=%#x, gisc=%#x, 
f=%#x," "gisa=%#x, isc=%#x, apqn=%#04x\n", __func__, 
status.response_code, aqic_gisa.zone, aqic_gisa.ir, aqic_gisa.gisc, 
aqic_gisa.gf, aqic_gisa.gisa, aqic_gisa.isc, q->apqn);

}

[PATCH 2/4] s390/vfio-ap: Fix failure to release IRQ notification eventfd contexts

[Anthony Krowiak]

When userspace registers IRQ notification eventfds via the
VFIO_DEVICE_SET_IRQS ioctl, vfio_ap_set_request_irq() and
vfio_ap_set_cfg_change_irq() each call eventfd_ctx_fdget(), which
takes a reference on the eventfd_ctx and stores it in
matrix_mdev->req_trigger and matrix_mdev->cfg_chg_trigger
respectively.

These references are dropped only when userspace explicitly replaces
or clears them via a subsequent SET_IRQS call.  If the device is
closed without that explicit teardown - because the guest exits,
the VM process crashes, or the device file is simply closed -
neither vfio_ap_mdev_close_device() nor the remove path releases
these references.  The eventfd_ctx backing objects and their
associated file references therefore leak for the lifetime of the
kernel.

Fix this by introducing vfio_ap_mdev_release_eventfds() and calling
it from vfio_ap_mdev_close_device() after vfio_ap_mdev_unset_kvm().
The VFIO core guarantees that close_device is called before
vfio_unregister_group_dev() returns in the remove path, so fixing
close_device is sufficient to cover both teardown paths.

Note:
~~~~
The matrix_dev->mdevs lock must be held during the call to
vfio_ap_mdev_release_eventfds(). There is a small window between the calls
to vfio_ap_mdev_unset_kvm() which gets and releases the update locks
and the acquisition of the matrix_dev->mdevs_lock mutex during which
it is possible - although highly unlikely during normal operation - whereby
a concurrent SET_IRQS call can get in.

Taking matrix_dev->mdevs_lock around vfio_ap_mdev_release_eventfds()
is sufficient to make this race-free. The SET_IRQS ioctl path writes
req_trigger and cfg_chg_trigger only from vfio_ap_mdev_ioctl(), which
holds mdevs_lock for its entire duration and always calls
eventfd_ctx_put() on the previous value before storing the new one.

Any number of concurrent SET_IRQS calls during the window between
vfio_ap_mdev_unset_kvm() and the acquisition of mdevs_lock are
therefore safe: each ioctl invocation puts the reference it found and
installs a new one, leaving exactly one live reference in the field
when it releases the lock. When release_eventfds subsequently acquires
mdevs_lock it finds that single surviving reference and puts it.
Conversely, a SET_IRQS call that loses the race and blocks on
mdevs_lock will find the field NULL after release_eventfds finishes,
take ownership of the reference it just created, and install it into a
field that will never be read again - a transient leak. To close that
final case, callers must ensure no new SET_IRQS ioctls can be issued
after close_device() is called, which the VFIO core guarantees by
releasing the device file before invoking close_device().

Fixes: bf48961f6f48e ("s390/vfio-ap: realize the VFIO_DEVICE_SET_IRQS ioctl")
Cc: stable@vger.kernel.org
Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
---
 drivers/s390/crypto/vfio_ap_ops.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
index a46bf381ab72..6e4569d6b975 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -2066,12 +2066,28 @@ static int vfio_ap_mdev_open_device(struct vfio_device *vdev)
 	return vfio_ap_mdev_set_kvm(matrix_mdev, vdev->kvm);
 }
 
+static void vfio_ap_mdev_release_eventfds(struct ap_matrix_mdev *matrix_mdev)
+{
+	if (matrix_mdev->req_trigger) {
+		eventfd_ctx_put(matrix_mdev->req_trigger);
+		matrix_mdev->req_trigger = NULL;
+	}
+	if (matrix_mdev->cfg_chg_trigger) {
+		eventfd_ctx_put(matrix_mdev->cfg_chg_trigger);
+		matrix_mdev->cfg_chg_trigger = NULL;
+	}
+}
+
 static void vfio_ap_mdev_close_device(struct vfio_device *vdev)
 {
 	struct ap_matrix_mdev *matrix_mdev =
 		container_of(vdev, struct ap_matrix_mdev, vdev);
 
 	vfio_ap_mdev_unset_kvm(matrix_mdev);
+
+	mutex_lock(&matrix_dev->mdevs_lock);
+	vfio_ap_mdev_release_eventfds(matrix_mdev);
+	mutex_unlock(&matrix_dev->mdevs_lock);
 }
 
 static void vfio_ap_mdev_request(struct vfio_device *vdev, unsigned int count)
-- 
2.53.0

Re: [PATCH 2/4] s390/vfio-ap: Fix failure to release IRQ notification eventfd contexts

[Matthew Rosato]

On 8/24/26 9:58 AM, Anthony Krowiak wrote:
> When userspace registers IRQ notification eventfds via the
> VFIO_DEVICE_SET_IRQS ioctl, vfio_ap_set_request_irq() and
> vfio_ap_set_cfg_change_irq() each call eventfd_ctx_fdget(), which
> takes a reference on the eventfd_ctx and stores it in
> matrix_mdev->req_trigger and matrix_mdev->cfg_chg_trigger
> respectively.
> 
> These references are dropped only when userspace explicitly replaces
> or clears them via a subsequent SET_IRQS call.  If the device is
> closed without that explicit teardown - because the guest exits,
> the VM process crashes, or the device file is simply closed -
> neither vfio_ap_mdev_close_device() nor the remove path releases
> these references.  The eventfd_ctx backing objects and their
> associated file references therefore leak for the lifetime of the
> kernel.
> 
> Fix this by introducing vfio_ap_mdev_release_eventfds() and calling
> it from vfio_ap_mdev_close_device() after vfio_ap_mdev_unset_kvm().
> The VFIO core guarantees that close_device is called before
> vfio_unregister_group_dev() returns in the remove path, so fixing
> close_device is sufficient to cover both teardown paths.
> 
> Note:
> ~~~~
> The matrix_dev->mdevs lock must be held during the call to
> vfio_ap_mdev_release_eventfds(). There is a small window between the calls
> to vfio_ap_mdev_unset_kvm() which gets and releases the update locks
> and the acquisition of the matrix_dev->mdevs_lock mutex during which
> it is possible - although highly unlikely during normal operation - whereby
> a concurrent SET_IRQS call can get in.
> 
> Taking matrix_dev->mdevs_lock around vfio_ap_mdev_release_eventfds()
> is sufficient to make this race-free. The SET_IRQS ioctl path writes
> req_trigger and cfg_chg_trigger only from vfio_ap_mdev_ioctl(), which
> holds mdevs_lock for its entire duration and always calls
> eventfd_ctx_put() on the previous value before storing the new one.
> 
> Any number of concurrent SET_IRQS calls during the window between
> vfio_ap_mdev_unset_kvm() and the acquisition of mdevs_lock are
> therefore safe: each ioctl invocation puts the reference it found and
> installs a new one, leaving exactly one live reference in the field
> when it releases the lock. When release_eventfds subsequently acquires
> mdevs_lock it finds that single surviving reference and puts it.
> Conversely, a SET_IRQS call that loses the race and blocks on
> mdevs_lock will find the field NULL after release_eventfds finishes,
> take ownership of the reference it just created, and install it into a
> field that will never be read again - a transient leak. To close that
> final case, callers must ensure no new SET_IRQS ioctls can be issued
> after close_device() is called, which the VFIO core guarantees by
> releasing the device file before invoking close_device().
> 
> Fixes: bf48961f6f48e ("s390/vfio-ap: realize the VFIO_DEVICE_SET_IRQS ioctl")
> Cc: stable@vger.kernel.org
> Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>

Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>

[PATCH 3/4] s390/vfio-ap: Fix unbounded loop in apq_reset_check()

[Anthony Krowiak]

The apq_reset_check() worker polls ap_tapq() in a while(true) loop
waiting for a queue reset to complete. When ap_tapq() returns
AP_RESPONSE_BUSY or AP_RESPONSE_RESET_IN_PROGRESS,
apq_status_check() returns -EBUSY and the loop continues after
sleeping AP_RESET_INTERVAL (20ms). There is no upper bound on how
many times the loop iterates, so if the hardware continuously
returns a busy response the worker runs indefinitely.

This is particularly harmful because several callers of
vfio_ap_mdev_reset_queues() and vfio_ap_mdev_reset_qlist() call
flush_work() on each queue's reset_work while holding one or more
of the global matrix_dev locks (guests_lock, mdevs_lock) or the
KVM lock. An indefinitely spinning worker permanently blocks all
of those locks, hanging mdev removal, KVM guest teardown, and the
VFIO_DEVICE_RESET ioctl path.

Fix this by introducing AP_RESET_TIMEOUT (2000ms) and breaking out
of the poll loop when elapsed time reaches that threshold. On
timeout the final busy status is written back to q->reset_status
so that callers inspecting reset_status.response_code after
flush_work() see a non-zero value and can return an appropriate
error. vfio_ap_free_aqic_resources() is called before returning
to release any KVM ISC registration and pinned NIB page,
consistent with all other early-exit paths in the function.

Fixes: dd174833e44e ("s390/vfio-ap: remove upper limit on wait for queue reset to complete")
Cc: stable@vger.kernel.org
Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
---
 drivers/s390/crypto/vfio_ap_ops.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
index 6e4569d6b975..c7eebbd0ed40 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -31,6 +31,7 @@
 #define AP_QUEUE_IN_USE "in use"
 
 #define AP_RESET_INTERVAL		20	/* Reset sleep interval (20ms)		*/
+#define AP_RESET_MAX_WAIT		2000	/* Maximum wait for reset (2000ms)	*/
 
 static int vfio_ap_mdev_reset_queues(struct ap_matrix_mdev *matrix_mdev);
 static int vfio_ap_mdev_reset_qlist(struct list_head *qlist);
@@ -1973,6 +1974,12 @@ static void apq_reset_check(struct work_struct *reset_work)
 					      status.response_code,
 					      status.queue_empty,
 					      status.irq_enabled);
+			if (elapsed >= AP_RESET_MAX_WAIT) {
+				/* Timed out waiting for reset to complete */
+				memcpy(&q->reset_status, &status, sizeof(status));
+				vfio_ap_free_aqic_resources(q);
+				return;
+			}
 		} else {
 			if (q->reset_status.response_code == AP_RESPONSE_RESET_IN_PROGRESS ||
 			    q->reset_status.response_code == AP_RESPONSE_BUSY ||
-- 
2.53.0

Re: [PATCH 3/4] s390/vfio-ap: Fix unbounded loop in apq_reset_check()

[Matthew Rosato]

On 8/24/26 9:58 AM, Anthony Krowiak wrote:
> The apq_reset_check() worker polls ap_tapq() in a while(true) loop
> waiting for a queue reset to complete. When ap_tapq() returns
> AP_RESPONSE_BUSY or AP_RESPONSE_RESET_IN_PROGRESS,
> apq_status_check() returns -EBUSY and the loop continues after
> sleeping AP_RESET_INTERVAL (20ms). There is no upper bound on how
> many times the loop iterates, so if the hardware continuously
> returns a busy response the worker runs indefinitely.
> 
> This is particularly harmful because several callers of
> vfio_ap_mdev_reset_queues() and vfio_ap_mdev_reset_qlist() call
> flush_work() on each queue's reset_work while holding one or more
> of the global matrix_dev locks (guests_lock, mdevs_lock) or the
> KVM lock. An indefinitely spinning worker permanently blocks all
> of those locks, hanging mdev removal, KVM guest teardown, and the
> VFIO_DEVICE_RESET ioctl path.
> 
> Fix this by introducing AP_RESET_TIMEOUT (2000ms) and breaking out

s/AP_RESET_TIMEOUT/AP_RESET_MAX_WAIT/ ?

> of the poll loop when elapsed time reaches that threshold. On
> timeout the final busy status is written back to q->reset_status
> so that callers inspecting reset_status.response_code after
> flush_work() see a non-zero value and can return an appropriate
> error. vfio_ap_free_aqic_resources() is called before returning
> to release any KVM ISC registration and pinned NIB page,
> consistent with all other early-exit paths in the function.
> 
> Fixes: dd174833e44e ("s390/vfio-ap: remove upper limit on wait for queue reset to complete")
> Cc: stable@vger.kernel.org
> Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
> ---
>  drivers/s390/crypto/vfio_ap_ops.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> index 6e4569d6b975..c7eebbd0ed40 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -31,6 +31,7 @@
>  #define AP_QUEUE_IN_USE "in use"
>  
>  #define AP_RESET_INTERVAL		20	/* Reset sleep interval (20ms)		*/
> +#define AP_RESET_MAX_WAIT		2000	/* Maximum wait for reset (2000ms)	*/
>  
>  static int vfio_ap_mdev_reset_queues(struct ap_matrix_mdev *matrix_mdev);
>  static int vfio_ap_mdev_reset_qlist(struct list_head *qlist);
> @@ -1973,6 +1974,12 @@ static void apq_reset_check(struct work_struct *reset_work)
>  					      status.response_code,
>  					      status.queue_empty,
>  					      status.irq_enabled);
> +			if (elapsed >= AP_RESET_MAX_WAIT) {
> +				/* Timed out waiting for reset to complete */
> +				memcpy(&q->reset_status, &status, sizeof(status));
> +				vfio_ap_free_aqic_resources(q);
> +				return;

Sashiko points out a concern here and I tend to agree; if this timer
elapses you are effectively freeing resources that could still be in-use.

This seems to go back to dd174833e44e 's390/vfio-ap: remove upper limit
on wait for queue reset to complete' where it was decided to hang
forever vs leak resources -- e.g. the hang seems intentional?

If we don't have a way of forcing firmware to give up the resources I
think we are stuck either waiting indefinitely or quarantining (leaking)
the resources consciously.  And documenting the rationale in a comment
block.

> +			}
>  		} else {
>  			if (q->reset_status.response_code == AP_RESPONSE_RESET_IN_PROGRESS ||
>  			    q->reset_status.response_code == AP_RESPONSE_BUSY ||

Re: [PATCH 3/4] s390/vfio-ap: Fix unbounded loop in apq_reset_check()

[Anthony Krowiak]

On 8/24/26 1:04 PM, Matthew Rosato wrote:
> On 8/24/26 9:58 AM, Anthony Krowiak wrote:
>> The apq_reset_check() worker polls ap_tapq() in a while(true) loop
>> waiting for a queue reset to complete. When ap_tapq() returns
>> AP_RESPONSE_BUSY or AP_RESPONSE_RESET_IN_PROGRESS,
>> apq_status_check() returns -EBUSY and the loop continues after
>> sleeping AP_RESET_INTERVAL (20ms). There is no upper bound on how
>> many times the loop iterates, so if the hardware continuously
>> returns a busy response the worker runs indefinitely.
>>
>> This is particularly harmful because several callers of
>> vfio_ap_mdev_reset_queues() and vfio_ap_mdev_reset_qlist() call
>> flush_work() on each queue's reset_work while holding one or more
>> of the global matrix_dev locks (guests_lock, mdevs_lock) or the
>> KVM lock. An indefinitely spinning worker permanently blocks all
>> of those locks, hanging mdev removal, KVM guest teardown, and the
>> VFIO_DEVICE_RESET ioctl path.
>>
>> Fix this by introducing AP_RESET_TIMEOUT (2000ms) and breaking out
> s/AP_RESET_TIMEOUT/AP_RESET_MAX_WAIT/ ?

I had to change that string at one time because the compiler
complained about the AP_RESET_TIMEOUT being a duplicate.
I'll fix it.

>
>> of the poll loop when elapsed time reaches that threshold. On
>> timeout the final busy status is written back to q->reset_status
>> so that callers inspecting reset_status.response_code after
>> flush_work() see a non-zero value and can return an appropriate
>> error. vfio_ap_free_aqic_resources() is called before returning
>> to release any KVM ISC registration and pinned NIB page,
>> consistent with all other early-exit paths in the function.
>>
>> Fixes: dd174833e44e ("s390/vfio-ap: remove upper limit on wait for queue reset to complete")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
>> ---
>>   drivers/s390/crypto/vfio_ap_ops.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
>> index 6e4569d6b975..c7eebbd0ed40 100644
>> --- a/drivers/s390/crypto/vfio_ap_ops.c
>> +++ b/drivers/s390/crypto/vfio_ap_ops.c
>> @@ -31,6 +31,7 @@
>>   #define AP_QUEUE_IN_USE "in use"
>>   
>>   #define AP_RESET_INTERVAL		20	/* Reset sleep interval (20ms)		*/
>> +#define AP_RESET_MAX_WAIT		2000	/* Maximum wait for reset (2000ms)	*/
>>   
>>   static int vfio_ap_mdev_reset_queues(struct ap_matrix_mdev *matrix_mdev);
>>   static int vfio_ap_mdev_reset_qlist(struct list_head *qlist);
>> @@ -1973,6 +1974,12 @@ static void apq_reset_check(struct work_struct *reset_work)
>>   					      status.response_code,
>>   					      status.queue_empty,
>>   					      status.irq_enabled);
>> +			if (elapsed >= AP_RESET_MAX_WAIT) {
>> +				/* Timed out waiting for reset to complete */
>> +				memcpy(&q->reset_status, &status, sizeof(status));
>> +				vfio_ap_free_aqic_resources(q);
>> +				return;
> Sashiko points out a concern here and I tend to agree; if this timer
> elapses you are effectively freeing resources that could still be in-use.
>
> This seems to go back to dd174833e44e 's390/vfio-ap: remove upper limit
> on wait for queue reset to complete' where it was decided to hang
> forever vs leak resources -- e.g. the hang seems intentional?
>
> If we don't have a way of forcing firmware to give up the resources I
> think we are stuck either waiting indefinitely or quarantining (leaking)
> the resources consciously.  And documenting the rationale in a comment
> block.
>
>> +			}
>>   		} else {
>>   			if (q->reset_status.response_code == AP_RESPONSE_RESET_IN_PROGRESS ||
>>   			    q->reset_status.response_code == AP_RESPONSE_BUSY ||

Re: [PATCH 3/4] s390/vfio-ap: Fix unbounded loop in apq_reset_check()

[Anthony Krowiak]

On 8/24/26 1:04 PM, Matthew Rosato wrote:
> On 8/24/26 9:58 AM, Anthony Krowiak wrote:
>> The apq_reset_check() worker polls ap_tapq() in a while(true) loop
>> waiting for a queue reset to complete. When ap_tapq() returns
>> AP_RESPONSE_BUSY or AP_RESPONSE_RESET_IN_PROGRESS,
>> apq_status_check() returns -EBUSY and the loop continues after
>> sleeping AP_RESET_INTERVAL (20ms). There is no upper bound on how
>> many times the loop iterates, so if the hardware continuously
>> returns a busy response the worker runs indefinitely.
>>
>> This is particularly harmful because several callers of
>> vfio_ap_mdev_reset_queues() and vfio_ap_mdev_reset_qlist() call
>> flush_work() on each queue's reset_work while holding one or more
>> of the global matrix_dev locks (guests_lock, mdevs_lock) or the
>> KVM lock. An indefinitely spinning worker permanently blocks all
>> of those locks, hanging mdev removal, KVM guest teardown, and the
>> VFIO_DEVICE_RESET ioctl path.
>>
>> Fix this by introducing AP_RESET_TIMEOUT (2000ms) and breaking out
> s/AP_RESET_TIMEOUT/AP_RESET_MAX_WAIT/ ?
>
>> of the poll loop when elapsed time reaches that threshold. On
>> timeout the final busy status is written back to q->reset_status
>> so that callers inspecting reset_status.response_code after
>> flush_work() see a non-zero value and can return an appropriate
>> error. vfio_ap_free_aqic_resources() is called before returning
>> to release any KVM ISC registration and pinned NIB page,
>> consistent with all other early-exit paths in the function.
>>
>> Fixes: dd174833e44e ("s390/vfio-ap: remove upper limit on wait for queue reset to complete")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
>> ---
>>   drivers/s390/crypto/vfio_ap_ops.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
>> index 6e4569d6b975..c7eebbd0ed40 100644
>> --- a/drivers/s390/crypto/vfio_ap_ops.c
>> +++ b/drivers/s390/crypto/vfio_ap_ops.c
>> @@ -31,6 +31,7 @@
>>   #define AP_QUEUE_IN_USE "in use"
>>   
>>   #define AP_RESET_INTERVAL		20	/* Reset sleep interval (20ms)		*/
>> +#define AP_RESET_MAX_WAIT		2000	/* Maximum wait for reset (2000ms)	*/
>>   
>>   static int vfio_ap_mdev_reset_queues(struct ap_matrix_mdev *matrix_mdev);
>>   static int vfio_ap_mdev_reset_qlist(struct list_head *qlist);
>> @@ -1973,6 +1974,12 @@ static void apq_reset_check(struct work_struct *reset_work)
>>   					      status.response_code,
>>   					      status.queue_empty,
>>   					      status.irq_enabled);
>> +			if (elapsed >= AP_RESET_MAX_WAIT) {
>> +				/* Timed out waiting for reset to complete */
>> +				memcpy(&q->reset_status, &status, sizeof(status));
>> +				vfio_ap_free_aqic_resources(q);
>> +				return;
> Sashiko points out a concern here and I tend to agree; if this timer
> elapses you are effectively freeing resources that could still be in-use.

Ironically, it was sashiko that precipitated this change given the
issue of hanging forever.

>
> This seems to go back to dd174833e44e 's390/vfio-ap: remove upper limit
> on wait for queue reset to complete' where it was decided to hang
> forever vs leak resources -- e.g. the hang seems intentional?

It may have been intentional, but I don't recall.

>
> If we don't have a way of forcing firmware to give up the resources I
> think we are stuck either waiting indefinitely or quarantining (leaking)
> the resources consciously.  And documenting the rationale in a comment
> block.

The AP architecture defines only a few instructions, none of which
provide a way to give up resources. I think it best to document this
in a comment block rather than waiting indefinitely. The
apq_reset_check() function is called under the matrix_dev->mdevs_lock
mutex which is a global lock that guards access to all active mdevs
in the system. Since the likelihood of this is happening is probably
extremely rare and the amount of storage leaked is not significant,
I think it makes more sense to allow things to proceed in this case.

>
>> +			}
>>   		} else {
>>   			if (q->reset_status.response_code == AP_RESPONSE_RESET_IN_PROGRESS ||
>>   			    q->reset_status.response_code == AP_RESPONSE_BUSY ||