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.
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.
Jason
