From: Anthony Krowiak <akrowiak@linux.ibm.com>
To: Halil Pasic <pasic@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, jjherne@linux.ibm.com,
borntraeger@de.ibm.com, cohuck@redhat.com,
mjrosato@linux.ibm.com, alex.williamson@redhat.com,
stable@vger.kernel.org
Subject: Re: [PATCH v3 2/2] s390/vfio-ap: fix unlinking of queues from the mdev
Date: Tue, 13 Sep 2022 10:53:49 -0400 [thread overview]
Message-ID: <7c222f64-3f06-5184-31c3-be557051c6fa@linux.ibm.com> (raw)
In-Reply-To: <20220913160708.50466335.pasic@linux.ibm.com>
On 9/13/22 10:07 AM, Halil Pasic wrote:
> On Tue, 23 Aug 2022 11:06:43 -0400
> Tony Krowiak <akrowiak@linux.ibm.com> wrote:
>
>> The vfio_ap_mdev_unlink_adapter and vfio_ap_mdev_unlink_domain functions
>> add the associated vfio_ap_queue objects to the hashtable that links them
>> to the matrix mdev to which their APQN is assigned. In order to unlink
>> them, they must be deleted from the hashtable; if not, they will continue
>> to be reset whenever userspace closes the mdev fd or removes the mdev.
>> This patch fixes that issue.
> I'm not so sure about that!
>
>> Cc: stable@vger.kernel.org
>> Fixes: 70aeefe574cb ("s390/vfio-ap: reset queues after adapter/domain unassignment")
>> Reported-by: Tony Krowiak <akrowiak@linux.ibm.com>
>> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
>> ---
>> drivers/s390/crypto/vfio_ap_ops.c | 6 ++----
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
>> index ee82207b4e60..2493926b5dfb 100644
>> --- a/drivers/s390/crypto/vfio_ap_ops.c
>> +++ b/drivers/s390/crypto/vfio_ap_ops.c
>> @@ -1049,8 +1049,7 @@ static void vfio_ap_mdev_unlink_adapter(struct ap_matrix_mdev *matrix_mdev,
>> if (q && qtable) {
>> if (test_bit_inv(apid, matrix_mdev->shadow_apcb.apm) &&
>> test_bit_inv(apqi, matrix_mdev->shadow_apcb.aqm))
>> - hash_add(qtable->queues, &q->mdev_qnode,
>> - q->apqn);
> Careful qtable->queues is not supposed to be the same as
> matrix_mdev->qtable.queues it is rather a function local
> qtable that you use to know which queues were unlinked and
> need resetting.
You are correct. This patch is unnecessary.
>
> Have a look at vfio_ap_mdev_hot_unplug_adapter()
>
>> + vfio_ap_unlink_queue_fr_mdev(q);
> IMHO this change is completely bogous. BTW
> vfio_ap_unlink_apqn_fr_mdev() a couple of lines above in the source
> (not seen in diff context) calls vfio_ap_unlink_queue_fr_mdev().
After further review, this patch is not only bogus, it is not necessary.
>
>> }
>> }
>> }
>> @@ -1236,8 +1235,7 @@ static void vfio_ap_mdev_unlink_domain(struct ap_matrix_mdev *matrix_mdev,
>> if (q && qtable) {
>> if (test_bit_inv(apid, matrix_mdev->shadow_apcb.apm) &&
>> test_bit_inv(apqi, matrix_mdev->shadow_apcb.aqm))
>> - hash_add(qtable->queues, &q->mdev_qnode,
>> - q->apqn);
>> + vfio_ap_unlink_queue_fr_mdev(q);
> Same as above...
>
> Regards,
> Halil
>
>> }
>> }
>> }
next prev parent reply other threads:[~2022-09-13 16:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-23 15:06 [PATCH v3 0/2] s390/vfio-ap: fix two problems discovered in the vfio_ap driver Tony Krowiak
2022-08-23 15:06 ` [PATCH v3 1/2] s390/vfio-ap: bypass unnecessary processing of AP resources Tony Krowiak
2022-09-15 3:00 ` Halil Pasic
2022-09-15 14:53 ` Christian Borntraeger
2022-09-15 15:03 ` Halil Pasic
2022-08-23 15:06 ` [PATCH v3 2/2] s390/vfio-ap: fix unlinking of queues from the mdev Tony Krowiak
2022-09-13 14:07 ` Halil Pasic
2022-09-13 14:40 ` Anthony Krowiak
2022-09-13 14:53 ` Anthony Krowiak [this message]
2022-08-29 13:28 ` [PATCH v3 0/2] s390/vfio-ap: fix two problems discovered in the vfio_ap driver Anthony Krowiak
2022-09-06 18:22 ` Anthony Krowiak
2022-09-06 23:17 ` Anthony Krowiak
2022-09-07 17:19 ` Halil Pasic
2022-09-13 13:22 ` 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=7c222f64-3f06-5184-31c3-be557051c6fa@linux.ibm.com \
--to=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=jjherne@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=stable@vger.kernel.org \
/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