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

[Tony Krowiak]

On 7/12/21 7:38 PM, Halil Pasic wrote:
> On Wed,  7 Jul 2021 11:41:56 -0400
> Tony Krowiak <akrowiak@xxxxxxxxxxxxx> 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