From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Keir Fraser <keir@xen.org>
Subject: Re: [PATCH] x86: fix ordering of operations in destroy_irq()
Date: Wed, 29 May 2013 08:29:42 +0100 [thread overview]
Message-ID: <CDCB6CF6.53C61%keir.xen@gmail.com> (raw)
In-Reply-To: <51A5C33A02000078000D974A@nat28.tlf.novell.com>
On 29/05/2013 07:58, "Jan Beulich" <JBeulich@suse.com> wrote:
> The fix for XSA-36, switching the default of vector map management to
> be per-device, exposed more readily a problem with the cleanup of these
> vector maps: dynamic_irq_cleanup() clearing desc->arch.used_vectors
> keeps the subsequently invoked clear_irq_vector() from clearing the
> bits for both the in-use and a possibly still outstanding old vector.
>
> Fix this by folding dynamic_irq_cleanup() into destroy_irq(), which was
> its only caller, deferring the clearing of the vector map pointer until
> after clear_irq_vector().
>
> Once at it, also defer resetting of desc->handler until after the loop
> around smp_mb() checking for IRQ_INPROGRESS to be clear, fixing a
> (mostly theoretical) issue with the intercation with do_IRQ(): If we
> don't defer the pointer reset, do_IRQ() could, for non-guest IRQs, call
> ->ack() and ->end() with different ->handler pointers, potentially
> leading to an IRQ remaining un-acked. The issue is mostly theoretical
> because non-guest IRQs are subject to destroy_irq() only on (boot time)
> error paths.
>
> As to the changed locking: Invoking clear_irq_vector() with desc->lock
> held is okay because vector_lock already nests inside desc->lock (proven
> by set_desc_affinity(), which takes vector_lock and gets called from
> various desc->handler->ack implementations, getting invoked with
> desc->lock held).
>
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -197,12 +197,24 @@ int create_irq(int node)
> return irq;
> }
>
> -static void dynamic_irq_cleanup(unsigned int irq)
> +void destroy_irq(unsigned int irq)
> {
> struct irq_desc *desc = irq_to_desc(irq);
> unsigned long flags;
> struct irqaction *action;
>
> + BUG_ON(!MSI_IRQ(irq));
> +
> + if ( dom0 )
> + {
> + int err = irq_deny_access(dom0, irq);
> +
> + if ( err )
> + printk(XENLOG_G_ERR
> + "Could not revoke Dom0 access to IRQ%u (error %d)\n",
> + irq, err);
> + }
> +
> spin_lock_irqsave(&desc->lock, flags);
> desc->status |= IRQ_DISABLED;
> desc->status &= ~IRQ_GUEST;
> @@ -210,16 +222,19 @@ static void dynamic_irq_cleanup(unsigned
> action = desc->action;
> desc->action = NULL;
> desc->msi_desc = NULL;
> - desc->handler = &no_irq_type;
> - desc->arch.used_vectors = NULL;
> cpumask_setall(desc->affinity);
> spin_unlock_irqrestore(&desc->lock, flags);
>
> /* Wait to make sure it's not being used on another CPU */
> do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
>
> - if (action)
> - xfree(action);
> + spin_lock_irqsave(&desc->lock, flags);
> + desc->handler = &no_irq_type;
> + clear_irq_vector(irq);
> + desc->arch.used_vectors = NULL;
> + spin_unlock_irqrestore(&desc->lock, flags);
> +
> + xfree(action);
> }
>
> static void __clear_irq_vector(int irq)
> @@ -286,24 +301,6 @@ void clear_irq_vector(int irq)
> spin_unlock_irqrestore(&vector_lock, flags);
> }
>
> -void destroy_irq(unsigned int irq)
> -{
> - BUG_ON(!MSI_IRQ(irq));
> -
> - if ( dom0 )
> - {
> - int err = irq_deny_access(dom0, irq);
> -
> - if ( err )
> - printk(XENLOG_G_ERR
> - "Could not revoke Dom0 access to IRQ%u (error %d)\n",
> - irq, err);
> - }
> -
> - dynamic_irq_cleanup(irq);
> - clear_irq_vector(irq);
> -}
> -
> int irq_to_vector(int irq)
> {
> int vector = -1;
>
>
>
next prev parent reply other threads:[~2013-05-29 7:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-29 6:58 [PATCH] x86: fix ordering of operations in destroy_irq() Jan Beulich
2013-05-29 7:23 ` Jan Beulich
2013-05-29 22:17 ` Andrew Cooper
2013-05-29 7:29 ` Keir Fraser [this message]
2013-05-30 16:23 ` George Dunlap
2013-05-30 16:42 ` Jan Beulich
2013-05-30 16:51 ` George Dunlap
2013-05-30 17:22 ` Andrew Cooper
2013-05-31 6:36 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CDCB6CF6.53C61%keir.xen@gmail.com \
--to=keir.xen@gmail.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.