From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Wed, 10 Jul 2013 23:08:37 +0000
Subject: Re: [PATCH 2/3] kvm/ppc: IRQ disabling cleanup
Message-Id: <1373497717.8183.237@snotra>
List-Id: <kvm-ppc.vger.kernel.org>
References: <1373496461-2668-1-git-send-email-scottwood@freescale.com>
	<1373496461-2668-3-git-send-email-scottwood@freescale.com>
	<266797C8-1BBB-4867-BB1B-ABCCF072536E@suse.de>
	<1373497280.19894.38.camel@pasglop>
	<328E7C2E-1D19-41D5-95F4-B0AFCA320208@suse.de>
In-Reply-To: <328E7C2E-1D19-41D5-95F4-B0AFCA320208@suse.de> (from
	agraf@suse.de on Wed Jul 10 18:04:53 2013)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Alexander Graf <agraf@suse.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>, "<kvm-ppc@vger.kernel.org>" <kvm-ppc@vger.kernel.org>, "<kvm@vger.kernel.org> list" <kvm@vger.kernel.org>

On 07/10/2013 06:04:53 PM, Alexander Graf wrote:
> 
> On 11.07.2013, at 01:01, Benjamin Herrenschmidt wrote:
> 
> > On Thu, 2013-07-11 at 00:57 +0200, Alexander Graf wrote:
> >>> #ifdef CONFIG_PPC64
> >>> +     /*
> >>> +      * To avoid races, the caller must have gone directly from  
> having
> >>> +      * interrupts fully-enabled to hard-disabled.
> >>> +      */
> >>> +     WARN_ON(local_paca->irq_happened != PACA_IRQ_HARD_DIS);
> >>
> >> WARN_ON(lazy_irq_pending()); ?
> >
> > Different semantics. What you propose will not catch irq_happened  
> = 0 :-)
> 
> Right, but we only ever reach here after hard_irq_disable() I think.

And the WARN_ON helps us ensure that it stays that way.

-Scott

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Subject: Re: [PATCH 2/3] kvm/ppc: IRQ disabling cleanup
Date: Wed, 10 Jul 2013 18:08:37 -0500
Message-ID: <1373497717.8183.237@snotra>
References: <1373496461-2668-1-git-send-email-scottwood@freescale.com>
	<1373496461-2668-3-git-send-email-scottwood@freescale.com>
	<266797C8-1BBB-4867-BB1B-ABCCF072536E@suse.de>
	<1373497280.19894.38.camel@pasglop>
	<328E7C2E-1D19-41D5-95F4-B0AFCA320208@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed
Content-Transfer-Encoding: 8BIT
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	"<kvm-ppc@vger.kernel.org>" <kvm-ppc@vger.kernel.org>,
	"<kvm@vger.kernel.org> list" <kvm@vger.kernel.org>
To: Alexander Graf <agraf@suse.de>
Return-path: <kvm-ppc-owner@vger.kernel.org>
In-Reply-To: <328E7C2E-1D19-41D5-95F4-B0AFCA320208@suse.de> (from
	agraf@suse.de on Wed Jul 10 18:04:53 2013)
Content-Disposition: inline
Sender: kvm-ppc-owner@vger.kernel.org
List-Id: kvm.vger.kernel.org

On 07/10/2013 06:04:53 PM, Alexander Graf wrote:
> 
> On 11.07.2013, at 01:01, Benjamin Herrenschmidt wrote:
> 
> > On Thu, 2013-07-11 at 00:57 +0200, Alexander Graf wrote:
> >>> #ifdef CONFIG_PPC64
> >>> +     /*
> >>> +      * To avoid races, the caller must have gone directly from  
> having
> >>> +      * interrupts fully-enabled to hard-disabled.
> >>> +      */
> >>> +     WARN_ON(local_paca->irq_happened != PACA_IRQ_HARD_DIS);
> >>
> >> WARN_ON(lazy_irq_pending()); ?
> >
> > Different semantics. What you propose will not catch irq_happened  
> == 0 :-)
> 
> Right, but we only ever reach here after hard_irq_disable() I think.

And the WARN_ON helps us ensure that it stays that way.

-Scott