From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH for 4.5] xen/arm: Initialize the domain vgic
	lock
Date: Thu, 18 Dec 2014 12:12:35 +0000
Message-ID: <1418904755.11882.43.camel@citrix.com>
References: <1418830815-4720-1-git-send-email-julien.grall@linaro.org>
	<1418896057.11882.0.camel@citrix.com> <5492C310.2050903@linaro.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1Zwd-00023f-Lp
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 12:12:39 +0000
In-Reply-To: <5492C310.2050903@linaro.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Julien Grall <julien.grall@linaro.org>
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com
List-Id: xen-devel@lists.xenproject.org

On Thu, 2014-12-18 at 12:05 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 18/12/2014 09:47, Ian Campbell wrote:
> > On Wed, 2014-12-17 at 15:40 +0000, Julien Grall wrote:
> >> The domain vgic lock is used uninitialized.
> >>
> >> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> >
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >
> >> ---
> >>      This is a bug fix for Xen 4.5 and Xen 4.4. The vgic lock is used
> >>      unitialized. Luckily we only use the field "raw" which is reset to 0
> >>      during the domain allocation.
> >>
> >>      There is no harm to apply for Xen 4.5 because it will correctly set
> >>      the spin_lock structure for a later usage.
> >
> > By your above reasoning there is also no point, is there? That said, I
> > think we should take this since as you say it is harmless and good
> > practice to initialise spinlocks even if not strictly necessary.
> 
> It's necessary to initialize spinlocks, not all the field of the 
> spinlock is using the value 0 at initialization time.

You said "...we only use the field "raw" which is reset to 0...". Was
that statement inaccurate?

> What I meant if the current usage is fine. But if we want to debug 
> spinlock, it won't work.
> 
> Regards,
>