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
