Re: [PATCH] s390/vfio-ap: do not open code locks for VFIO_GROUP_NOTIFY_SET_KVM notification

Tony Krowiak
2021-07-13T13:48:09Z

On 7/12/21 7:38 PM, Halil Pasic wrote:
> On Wed, 7 Jul 2021 11:41:56 -0400
> Tony Krowiak <akrowiak@linux.ibm.com> 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 the kvm_busy flag and sleeping on a wait_event is the same thing
>> a lock does. Whatever potential deadlock was found and reported via the
>> lockdep splat was not magically removed by going to a wait_queue; it just
>> removed the lockdep annotations that would identify the issue early
> Did you change your opinion since we last talked about it? This reads to
> me like we are deadlocky without this patch, because of the last
> sentence.

The words are a direct paraphrase of Jason G's responses to my
query regarding what he meant by open coding locks. I
am choosing to take his word on the subject and remove the
open coded locks.

Having said that, we do not have a deadlock problem without
this patch. If you recall, the lockdep splat occurred ONLY when
running a Secure Execution guest in a CI environment. Since
AP is not yet supported for SE guests, there is no danger of
a lockdep splat occurring in a customer environment. Given
Jason's objections to the original solution (i.e., kvm_busy flag
and wait queue), I decided to replace the so-called open
coded locks.

>
> Regards,
> Halil