[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Oct 2018 12:53:38 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Juergen Gross <jgross@...e.com>, linux-kernel@...r.kernel.org,
xen-devel@...ts.xenproject.org, x86@...nel.org
Cc: boris.ostrovsky@...cle.com, hpa@...or.com, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, stable@...r.kernel.org,
Waiman.Long@...com, peterz@...radead.org
Subject: Re: [PATCH 2/2] xen: make xen_qlock_wait() nestable
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?
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)
Powered by blists - more mailing lists