Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 7 Oct 2022 17:28:43 +0000
From:   Sean Christopherson <seanjc@google.com>
To:     Hao Peng <flyingpenghao@gmail.com>
Cc:     pbonzini@redhat.com, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kvm: x86: Keep the lock order consistent
Message-ID: <Y0Bhy/z+1Z1seT2d@google.com>
References: <CAPm50a+gcug5XOsg_Z=7R+3j+VUxHMrzyGNbps7-okR625KB_w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPm50a+gcug5XOsg_Z=7R+3j+VUxHMrzyGNbps7-okR625KB_w@mail.gmail.com>
Precedence: bulk

On Fri, Oct 07, 2022, Hao Peng wrote:
> From: Peng Hao <flyingpeng@tencent.com>
> 
> srcu read side in critical section may sleep, so it should precede
> the read lock,

I agree with the patch, but not necessarily with this statement.  The above
implies that it's not safe to acquire SRCU while in a non-sleepable context,
which is incorrect.  E.g. at first I thought the above implied there is an
incorrect sleep buried in this code.

> while other paths such as kvm_xen_set_evtchn_fast

Please put parantheses after function names, e.g. kvm_xen_set_evtchn_fast()
and srcu_read_lock().

> execute srcu_read_lock before acquiring the read lock.

How about this for a changelog?

  Acquire SRCU before taking the gpc spinlock in wait_pending_event() so as
  to be consistent with all other functions that acquire both locks.  It's
  not illegal to acquire SRCU inside a spinlock, nor is there deadlock
  potential, but in general it's preferable to order locks from least
  restrictive to most restrictive, e.g. if wait_pending_event() needed to
  sleep for whatever reason, it could do so while holding SRCU, but would
  need to drop the spinlock.