From: Tony Krowiak <akrowiak@linux.ibm.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
borntraeger@de.ibm.com, cohuck@redhat.com,
pasic@linux.vnet.ibm.com, jjherne@linux.ibm.com,
alex.williamson@redhat.com, kwankhede@nvidia.com
Subject: Re: [PATCH v3 2/2] s390/vfio-ap: control access to PQAP(AQIC) interception handler
Date: Wed, 19 May 2021 19:04:46 -0400 [thread overview]
Message-ID: <8c93c29a-e223-ac9a-5b54-7329587084c9@linux.ibm.com> (raw)
In-Reply-To: <20210519161610.GO1002214@nvidia.com>
On 5/19/21 12:16 PM, Jason Gunthorpe wrote:
> On Wed, May 19, 2021 at 11:39:21AM -0400, Tony Krowiak wrote:
>
>> @@ -287,13 +289,17 @@ static int handle_pqap(struct kvm_vcpu *vcpu)
>> if (!(vcpu->arch.sie_block->eca & ECA_AIV))
>> return -EOPNOTSUPP;
>>
>> - apqn = vcpu->run->s.regs.gprs[0] & 0xffff;
>> - mutex_lock(&matrix_dev->lock);
>> + rcu_read_lock();
>> + pqap_module_hook = rcu_dereference(vcpu->kvm->arch.crypto.pqap_hook);
>> + if (!pqap_module_hook) {
>> + rcu_read_unlock();
>> + goto set_status;
>> + }
>>
>> - if (!vcpu->kvm->arch.crypto.pqap_hook)
>> - goto out_unlock;
>> - matrix_mdev = container_of(vcpu->kvm->arch.crypto.pqap_hook,
>> - struct ap_matrix_mdev, pqap_hook);
>> + matrix_mdev = pqap_module_hook->data;
>> + rcu_read_unlock();
>> + mutex_lock(&matrix_dev->lock);
> The matrix_mdev pointer was extracted from the pqap_module_hook,
> but now there is nothing protecting it since the rcu was dropped and
> it gets freed in vfio_ap_mdev_remove.
Therein lies the rub. We can't hold the rcu_read_lock across the
entire time that the interception is being processed because of
wait conditions in the interception handler. Regardless of whether
the pointer to the matrix_mdev is retrieved as the container of
or extracted from the pqap_hook, there is nothing protecting it
and there appears to be no way to do so using RCU.
>
> And, again, module locking doesn't prevent vfio_ap_mdev_remove() from
> being called. None of these patches should be combining module locking
> with RCU.
Is there any other way besides user interaction with the mdev's
sysfs remove interface for the remove callback to get invoked?
If I try to remove the mdev using the sysfs interface while the
mdev fd is still open by the guest, the remove hangs until the
fd is closed. That being the case, the mdev release callback
will get invoked prior to the remove callback being invoked which
renders this whole debate moot. What am I missing here?
>
> Jason
next prev parent reply other threads:[~2021-05-19 23:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-19 15:39 [PATCH v3 0/2] s390/vfio-ap: fix memory leak in mdev remove callback Tony Krowiak
2021-05-19 15:39 ` [PATCH v3 1/2] " Tony Krowiak
2021-05-19 15:39 ` [PATCH v3 2/2] s390/vfio-ap: control access to PQAP(AQIC) interception handler Tony Krowiak
2021-05-19 16:16 ` Jason Gunthorpe
2021-05-19 23:04 ` Tony Krowiak [this message]
2021-05-19 23:22 ` Jason Gunthorpe
2021-05-20 1:08 ` Tony Krowiak
2021-05-20 8:48 ` Halil Pasic
2021-05-20 12:26 ` Jason Gunthorpe
2021-05-20 8:38 ` Halil Pasic
2021-05-20 12:51 ` Jason Gunthorpe
2021-05-21 18:24 ` Tony Krowiak
2021-05-21 18:30 ` Jason Gunthorpe
2021-05-19 17:21 ` Halil Pasic
2021-05-19 23:14 ` Tony 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=8c93c29a-e223-ac9a-5b54-7329587084c9@linux.ibm.com \
--to=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=jgg@nvidia.com \
--cc=jjherne@linux.ibm.com \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pasic@linux.vnet.ibm.com \
/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