linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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,
	frankja@linux.ibm.com, david@redhat.com, imbrenda@linux.ibm.com,
	hca@linux.ibm.com
Subject: Re: [PATCH v4 2/2] s390/vfio-ap: control access to PQAP(AQIC) interception handler
Date: Tue, 25 May 2021 10:59:25 -0400	[thread overview]
Message-ID: <ac5cfe4a-a61b-2226-58aa-a5ea761180be@linux.ibm.com> (raw)
In-Reply-To: <20210523225746.GF1002214@nvidia.com>



On 5/23/21 6:57 PM, Jason Gunthorpe wrote:
> On Fri, May 21, 2021 at 03:36:48PM -0400, Tony Krowiak wrote:
>> +static struct kvm_s390_crypto_hook
>> +*kvm_arch_crypto_find_hook(enum kvm_s390_crypto_hook_type type)
>> +{
>> +	struct kvm_s390_crypto_hook *crypto_hook;
>> +
>> +	list_for_each_entry(crypto_hook, &crypto_hooks, node) {
>> +		if (crypto_hook->type == type)
>> +			return crypto_hook;
>> +	}
>> +
>> +	return NULL;
>> +}
>> +
>> +int kvm_arch_crypto_register_hook(struct kvm_s390_crypto_hook *hook)
>> +{
>> +	struct kvm_s390_crypto_hook *crypto_hook;
>> +
>> +	mutex_lock(&crypto_hooks_lock);
>> +	crypto_hook = kvm_arch_crypto_find_hook(hook->type);
>> +	if (crypto_hook) {
>> +		if (crypto_hook->owner != hook->owner)
>> +			return -EACCES;
>> +		list_replace(&crypto_hook->node, &hook->node);
> This is all dead code right? This is only called from a module init
> function so it can't be called twice.

That is true only if you are considering the current case.
Is it guaranteed that only the vfio_ap module
will call this function and is there a guarantee that it will
always and only be called from the vfio_ap module init
function? For example, suppose a hook is added to
intercept the AP NQAP or DQAP instruction? We don't
know how or when those handlers will be registered
or unregistered. We don't even know if the handlers
will be part of the vfio_ap module or not.

> Just always fail if the hook is
> already used and delete the owner stuff.

I suppose that is reasonable and simpler.

>
> But this is alot of complicated and unused code to solve a lock
> ordering problem..

If you have a better solution, I'm all ears. I've been down this
road a couple of times now and solving lock ordering for
multiple asynchronous processes is not trivial. This seems like
a reasonable solution and provides for flexibility for including
additional hooks to handle interception of other AP instructions.

>
> Jason


  reply	other threads:[~2021-05-25 14:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21 19:36 [PATCH v4 0/2] s390/vfio-ap: fix memory leak in mdev remove callback Tony Krowiak
2021-05-21 19:36 ` [PATCH v4 1/2] " Tony Krowiak
2021-05-25 13:03   ` Halil Pasic
2021-05-25 13:22     ` Tony Krowiak
2021-05-26 12:37     ` Tony Krowiak
2021-05-21 19:36 ` [PATCH v4 2/2] s390/vfio-ap: control access to PQAP(AQIC) interception handler Tony Krowiak
2021-05-23 22:57   ` Jason Gunthorpe
2021-05-25 14:59     ` Tony Krowiak [this message]
2021-05-25 15:00       ` Jason Gunthorpe
2021-05-24 14:37   ` Jason J. Herne
2021-05-25 13:16     ` Tony Krowiak
2021-05-25 13:19       ` Jason Gunthorpe
2021-05-25 15:08         ` Tony Krowiak
2021-05-25 15:11           ` Jason Gunthorpe
2021-05-25 15:56         ` Tony Krowiak
2021-05-25 16:29           ` Jason Gunthorpe
2021-05-27  2:28             ` Tony Krowiak
2021-05-27 11:24               ` Jason Gunthorpe
2021-05-25 13:24     ` Jason J. Herne
2021-05-25 13:26       ` Jason Gunthorpe
2021-05-25 14:07         ` Jason J. Herne
2021-05-25 14:16           ` Jason Gunthorpe
2021-06-14  7:51 ` [PATCH v4 0/2] s390/vfio-ap: fix memory leak in mdev remove callback Christian Borntraeger
2021-06-16 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=ac5cfe4a-a61b-2226-58aa-a5ea761180be@linux.ibm.com \
    --to=akrowiak@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.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;
as well as URLs for NNTP newsgroup(s).