Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH 2/2] s390/vfio-ap: replace open coded locks for
 VFIO_GROUP_NOTIFY_SET_KVM notification
To:     Halil Pasic <pasic@linux.ibm.com>, 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, david@redhat.com,
        pbonzini@redhat.com, David Hildenbrand <david@redhat.com>,
        frankja@linux.ibm.com, imbrenda@linux.ibm.com
References: <20210719193503.793910-1-akrowiak@linux.ibm.com>
 <20210719193503.793910-3-akrowiak@linux.ibm.com>
 <20210721164550.5402fe1c.pasic@linux.ibm.com>
 <c3b80f79-6795-61ce-2dd1-f4cc7110e417@linux.ibm.com>
 <20210723162625.59cead27.pasic@linux.ibm.com>
 <5380652f-e68f-bbd0-10c0-c7d541065843@linux.ibm.com>
 <20210726223628.4d7759bf.pasic@linux.ibm.com>
 <20210726220317.GA1721383@nvidia.com>
 <20210727004329.3bcc7d4f.pasic@linux.ibm.com>
From:   Tony Krowiak <akrowiak@linux.ibm.com>
Message-ID: <a5eeac87-069d-171b-5558-3e99e7bda539@linux.ibm.com>
Date:   Wed, 28 Jul 2021 09:43:03 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <20210727004329.3bcc7d4f.pasic@linux.ibm.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk


On 7/26/21 6:43 PM, Halil Pasic wrote:
> On Mon, 26 Jul 2021 19:03:17 -0300
> Jason Gunthorpe <jgg@nvidia.com> wrote:
>
>>> You may end up with open and close running interleaved. What I'
>>> trying to say is, to my best knowledge, normally there is no
>>> you have to close it before you open it again rule for files.
>> This is an existing bug in this driver, I've fixed in the reflck series.
>>
>> open_device/close_device will not run concurrently, or out of order,
>> afer it is fixed.
> Well if that is the case then provided your fix precedes this patch:
>
> Acked-by: Halil Pasic <pasic@linux.ibm.com>
>
> I'm not entirely happy with this. I did not thoroughly investigate the
> implications of reversing the locking order of the vfio-ap lock (driver
> global) and the kvm lock (guest specific). I will trust Tony and hope
> our KVM maintainers will scream if this is bad from interference and
> delay perspective.

This solution was suggested by Jason G and it does in fact resolve
the lockdep splat encountered when starting an SE guest with
access to crypto resources. There is a chance that the KVM lock
can get held while waiting for the lock on the matrix_dev->mutex,
but this does not seem like a grave concern to me. That would
only happen during VFIO_GROUP_NOTIFY_SET_KVM notification - either
when the guest is being started or terminated, or when the mdev
fd is opened or closed. According to Jason, once he integrates his reflck
series, the open/close will happen only once.

I've copied the KVM maintainers on this response, so hopefully one of
them will provide some input.

>
> Regards,
> Halil