linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jason J. Herne" <jjherne@linux.ibm.com>
To: Tony Krowiak <akrowiak@linux.ibm.com>,
	linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: borntraeger@de.ibm.com, cohuck@redhat.com,
	pasic@linux.vnet.ibm.com, jgg@nvidia.com,
	alex.williamson@redhat.com, kwankhede@nvidia.com,
	david@redhat.com
Subject: Re: [PATCH 2/2] s390/vfio-ap: replace open coded locks for VFIO_GROUP_NOTIFY_SET_KVM notification
Date: Wed, 21 Jul 2021 15:37:46 -0400	[thread overview]
Message-ID: <6c7244b5-be7b-1566-f406-4c4c37f06fd7@linux.ibm.com> (raw)
In-Reply-To: <20210719193503.793910-3-akrowiak@linux.ibm.com>

On 7/19/21 3:35 PM, Tony Krowiak wrote:
> It was pointed out during an unrelated patch review that locks should not
> be open coded - i.e., writing the algorithm of a standard lock in a
> function instead of using a lock from the standard library. The setting and
> testing of a busy flag and sleeping on a wait_event is the same thing
> a lock does. The open coded locks are invisible to lockdep, so potential
> locking problems are not detected.
> 
> This patch removes the open coded locks used during
> VFIO_GROUP_NOTIFY_SET_KVM notification. The busy flag
> and wait queue were introduced to resolve a possible circular locking
> dependency reported by lockdep when starting a secure execution guest
> configured with AP adapters and domains. Reversing the order in which
> the kvm->lock mutex and matrix_dev->lock mutex are locked resolves the
> issue reported by lockdep, thus enabling the removal of the open coded
> locks.
> 
> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
> ---
>   arch/s390/kvm/kvm-s390.c              |  27 +++++-
>   drivers/s390/crypto/vfio_ap_ops.c     | 132 ++++++++------------------
>   drivers/s390/crypto/vfio_ap_private.h |   2 -
>   3 files changed, 63 insertions(+), 98 deletions(-)
> 
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index a08f242a9f27..4d2ef3a3286e 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -2559,12 +2559,24 @@ static void kvm_s390_set_crycb_format(struct kvm *kvm)
>   		kvm->arch.crypto.crycbd |= CRYCB_FORMAT1;
>   }
>   
> +/*
> + * kvm_arch_crypto_set_masks
> + *
> + * @kvm: a pointer to the object containing the crypto masks

This should probably say "a pointer to the target guest's KVM struct" or something to that 
effect. Same comment for the comment above kvm_arch_crypto_clear_masks.

> + * @apm: the mask identifying the accessible AP adapters
> + * @aqm: the mask identifying the accessible AP domains
> + * @adm: the mask identifying the accessible AP control domains
> + *
> + * Set the masks that identify the adapters, domains and control domains to
> + * which the KVM guest is granted access.
> + *
> + * Note: The kvm->lock mutex must be locked by the caller.
> + */
>   void kvm_arch_crypto_set_masks(struct kvm *kvm, unsigned long *apm,
>   			       unsigned long *aqm, unsigned long *adm)
>   {
>   	struct kvm_s390_crypto_cb *crycb = kvm->arch.crypto.crycb;
>   
> -	mutex_lock(&kvm->lock);
>   	kvm_s390_vcpu_block_all(kvm);
>   
>   	switch (kvm->arch.crypto.crycbd & CRYCB_FORMAT_MASK) {
> @@ -2595,13 +2607,21 @@ void kvm_arch_crypto_set_masks(struct kvm *kvm, unsigned long *apm,
>   	/* recreate the shadow crycb for each vcpu */
>   	kvm_s390_sync_request_broadcast(kvm, KVM_REQ_VSIE_RESTART);
>   	kvm_s390_vcpu_unblock_all(kvm);
> -	mutex_unlock(&kvm->lock);
>   }
>   EXPORT_SYMBOL_GPL(kvm_arch_crypto_set_masks);
>   
> +/*
> + * kvm_arch_crypto_set_masks

Copy/paste error here. Rename to kvm_arch_crypto_CLEAR_masks

I did not find anything else in my review. However, I'm still very new to this code, so 
take that with a grain of salt :).

Also, I could not apply this to master. If there is a next version do you mind rebasing? 
Seeing the patch in full context would be helpful.


-- 
-- Jason J. Herne (jjherne@linux.ibm.com)

  parent reply	other threads:[~2021-07-21 19:37 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-19 19:35 [PATCH 0/2] s390/vfio-ap: do not open code locks for VFIO_GROUP_NOTIFY_SET_KVM notification Tony Krowiak
2021-07-19 19:35 ` [PATCH 1/2] s390/vfio-ap: r/w lock for PQAP interception handler function pointer Tony Krowiak
2021-08-18 17:03   ` Christian Borntraeger
2021-08-18 23:25     ` Halil Pasic
2021-08-19  6:56       ` Christian Borntraeger
2021-08-19 13:36       ` Tony Krowiak
2021-08-19 21:42         ` Halil Pasic
2021-08-23 13:08           ` Tony Krowiak
2021-08-19 13:20     ` Tony Krowiak
2021-08-19 17:54       ` Alex Williamson
2021-08-19 17:58         ` Jason Gunthorpe
2021-08-20 15:59           ` Tony Krowiak
2021-08-20 22:05           ` Tony Krowiak
2021-08-20 22:30             ` Jason Gunthorpe
2021-08-23 15:17               ` Tony Krowiak
2021-08-20 22:41             ` Alex Williamson
2021-08-23 20:51               ` Tony Krowiak
2021-07-19 19:35 ` [PATCH 2/2] s390/vfio-ap: replace open coded locks for VFIO_GROUP_NOTIFY_SET_KVM notification Tony Krowiak
2021-07-21 14:45   ` Halil Pasic
2021-07-22 13:09     ` Tony Krowiak
2021-07-23 14:26       ` Halil Pasic
2021-07-23 21:24         ` Tony Krowiak
2021-07-26 20:36           ` Halil Pasic
2021-07-26 22:03             ` Jason Gunthorpe
2021-07-26 22:43               ` Halil Pasic
2021-07-28 13:43                 ` Tony Krowiak
2021-07-28 19:42                   ` Halil Pasic
2021-07-30 13:33                     ` Tony Krowiak
2021-07-27  6:54               ` Christoph Hellwig
2021-07-21 19:37   ` Jason J. Herne [this message]
2021-07-22 13:16     ` Tony Krowiak
2021-08-02 13:10 ` [PATCH 0/2] s390/vfio-ap: do not open code " Tony Krowiak
2021-08-02 13:53   ` Halil Pasic
2021-08-02 16:32     ` Tony Krowiak
2021-08-03 13:08       ` Jason Gunthorpe
2021-08-03 13:34         ` Tony Krowiak
2021-08-18 15:59       ` Christian Borntraeger
2021-08-18 16:39         ` Alex Williamson
2021-08-18 16:50           ` Christian Borntraeger
2021-08-18 22:52             ` Halil Pasic
2021-08-19 15:30           ` Cornelia Huck
2021-08-20 14:24             ` 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=6c7244b5-be7b-1566-f406-4c4c37f06fd7@linux.ibm.com \
    --to=jjherne@linux.ibm.com \
    --cc=akrowiak@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=jgg@nvidia.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;
as well as URLs for NNTP newsgroup(s).