From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Yang, Xiaowei" Subject: Re: [PATCH] Fix memory order issue inside pv spinlock Date: Thu, 10 Sep 2009 00:30:00 +0800 Message-ID: <4AA7D808.6010108@intel.com> References: <4AA4B8FF.9070905@intel.com> <4AA6D3CF.70905@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4AA6D3CF.70905@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Jeremy Fitzhardinge wrote: > On 09/07/09 00:40, Yang, Xiaowei wrote: >> barrier() can't prevent reads after it not being reordered with older >> writes to different locates before it. Because of it, I can't bring up >>> 4 HVM guests on one SMP machine. Use mb() instead. > > Which read is happening too early? Is it "xl->spinners"? How does it fail? Yes. If read of xl->spinners happens earlier than write 0 to xl->lock, notifications to wake up other spinners can be omitted incorrectly, resulting in others polling indefinitely (because of poll evtchn not pending) with the lock is uncontended. Thanks, xiaowei > > Thanks, > J > >> Signed-off-by: Yang Xiaowei >> >> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c >> index 5601506..9dee5f8 100644 >> --- a/arch/x86/xen/spinlock.c >> +++ b/arch/x86/xen/spinlock.c >> @@ -324,7 +325,7 @@ static void xen_spin_unlock(struct raw_spinlock >> *lock) >> xl->lock = 0; /* release lock */ >> >> /* make sure unlock happens before kick */ >> - barrier(); >> + mb(); >> >> if (unlikely(xl->spinners)) >> xen_spin_unlock_slow(xl); >> >> Thanks, >> Xiaowei >> >