xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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;
> 
> 
> 

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).