linux-kernel - Re: [PATCH] s390: vfio-ap: disable IRQ in remove callback results in kernel OOPS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <0565c250-726f-dd99-f933-f91162dc107e@linux.ibm.com>
Date:   Wed, 30 Oct 2019 08:44:11 +0100
From:   Harald Freudenberger <freude@...ux.ibm.com>
To:     Tony Krowiak <akrowiak@...ux.ibm.com>, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Cc:     heiko.carstens@...ibm.com, gor@...ux.ibm.com,
        borntraeger@...ibm.com, cohuck@...hat.com, mjrosato@...ux.ibm.com,
        pmorel@...ux.ibm.com, pasic@...ux.ibm.com, jjherne@...ux.ibm.com
Subject: Re: [PATCH] s390: vfio-ap: disable IRQ in remove callback results in
 kernel OOPS

On 29.10.19 23:09, Tony Krowiak wrote:
> From: aekrowia <akrowiak@...ux.ibm.com>
>
> When an AP adapter card is configured off via the SE or the SCLP
> Deconfigure Adjunct Processor command and the AP bus subsequently detects
> that the adapter card is no longer in the AP configuration, the card
> device representing the adapter card as well as each of its associated
> AP queue devices will be removed by the AP bus. If one or more of the
> affected queue devices is bound to the VFIO AP device driver, its remove
> callback will be invoked for each queue to be removed. The remove callback
> resets the queue and disables IRQ processing. If interrupt processing was
> never enabled for the queue, disabling IRQ processing will fail resulting
> in a kernel OOPS.
>
> This patch verifies IRQ processing is enabled before attempting to disable
> interrupts for the queue.
>
> Signed-off-by: Tony Krowiak <akrowiak@...ux.ibm.com>
> Signed-off-by: aekrowia <akrowiak@...ux.ibm.com>
> ---
>  drivers/s390/crypto/vfio_ap_drv.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/s390/crypto/vfio_ap_drv.c b/drivers/s390/crypto/vfio_ap_drv.c
> index be2520cc010b..42d8308fd3a1 100644
> --- a/drivers/s390/crypto/vfio_ap_drv.c
> +++ b/drivers/s390/crypto/vfio_ap_drv.c
> @@ -79,7 +79,8 @@ static void vfio_ap_queue_dev_remove(struct ap_device *apdev)
>  	apid = AP_QID_CARD(q->apqn);
>  	apqi = AP_QID_QUEUE(q->apqn);
>  	vfio_ap_mdev_reset_queue(apid, apqi, 1);
> -	vfio_ap_irq_disable(q);
> +	if (q->saved_isc != VFIO_AP_ISC_INVALID)
> +		vfio_ap_irq_disable(q);
>  	kfree(q);
>  	mutex_unlock(&matrix_dev->lock);
>  }
Reset of an APQN does also clear IRQ processing. I don't say that the
resources associated with IRQ handling for the APQN are also cleared.
But when you call PQAP(AQIC) after an PQAP(RAPQ) or PQAP(ZAPQ)
it is superfluous. However, there should not appear any kernel OOPS.
So can you please give me more details about this kernel oops - maybe
I need to add exception handler code to the inline ap_aqic() function.

regards, Harald Freudenberger