Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 10 Oct 2018 14:30:17 +0200 (CEST)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     David Woodhouse <dwmw2@infradead.org>
cc:     Juergen Gross <jgross@suse.com>, linux-kernel@vger.kernel.org,
        xen-devel@lists.xenproject.org, x86@kernel.org,
        boris.ostrovsky@oracle.com, hpa@zytor.com, mingo@redhat.com,
        bp@alien8.de, stable@vger.kernel.org, Waiman.Long@hp.com,
        peterz@infradead.org
Subject: Re: [PATCH 2/2] xen: make xen_qlock_wait() nestable
In-Reply-To: <47686a61dfc06aa5afb05a893b9a56e6eb46763d.camel@infradead.org>
Message-ID: <alpine.DEB.2.21.1810101426080.10278@nanos.tec.linutronix.de>
References: <20181001071641.19282-1-jgross@suse.com>         <20181001071641.19282-3-jgross@suse.com> <47686a61dfc06aa5afb05a893b9a56e6eb46763d.camel@infradead.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, 10 Oct 2018, David Woodhouse wrote:

> On Mon, 2018-10-01 at 09:16 +0200, Juergen Gross wrote:
> > -       /* If irq pending already clear it and return. */
> > +       /* Guard against reentry. */
> > +       local_irq_save(flags);
> > +
> > +       /* If irq pending already clear it. */
> >         if (xen_test_irq_pending(irq)) {
> >                 xen_clear_irq_pending(irq);
> > -               return;
> > +       } else if (READ_ONCE(*byte) == val) {
> > +               /* Block until irq becomes pending (or a spurious wakeup) */
> > +               xen_poll_irq(irq);
> >         }
> 
> 
> Does this still allow other IRQs to wake it from xen_poll_irq()?
> 
> In the case where process-context code is spinning for a lock without
> disabling interrupts, we *should* allow interrupts to occur still...
> does this?

Yes. Look at it like idle HLT or WFI. You have to disable interrupt before
checking the condition and then the hardware or in this case the hypervisor
has to bring you back when an interrupt is raised.

If that would not work then the check would be racy, because the interrupt
could hit and be handled after the check and before going into
HLT/WFI/hypercall and then the thing is out until the next interrupt comes
along, which might be never.

Thanks,

	tglx