Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1300845 > unrolled thread

Re: [patch 00/14] x86/irq: Plug various vector cleanup races

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [patch 00/14] x86/irq: Plug various vector cleanup races Joe Lawrence <joe.lawrence@stratus.com> - 2016-01-04 17:00 +0100
    Re: [patch 00/14] x86/irq: Plug various vector cleanup races Thomas Gleixner <tglx@linutronix.de> - 2016-01-14 09:30 +0100
      Re: [patch 00/14] x86/irq: Plug various vector cleanup races Borislav Petkov <bp@alien8.de> - 2016-01-14 11:40 +0100

#1300845 — Re: [patch 00/14] x86/irq: Plug various vector cleanup races

On 12/31/2015 11:30 AM, Thomas Gleixner wrote:
> Joe reported a nasty race in the vector cleanup code which results in stale
> irq descriptors in the vector arrays and a potential use after free.
> 
> This series addresses this issue, another race which was found and fixed by
> Jiang related to the same area, plus a cpu hotplug issue which is not related
> to this.
> 
> This lot is intended for stable, but not yet marked so. The diffstat below is
> rather large, but this is mostly due to extensive commentry which I added in
> the process.

Hi Thomas,

No issues running the same PCI device removal and stress tests against
the patchset.

Thanks,

Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1309068

On Mon, 4 Jan 2016, Joe Lawrence wrote:
> No issues running the same PCI device removal and stress tests against
> the patchset.

Thanks for testing!

Though there is yet another long standing bug in that area. Fix below.

Thanks,

	tglx

8<--------------------

Subject: x86/irq: Call chip->irq_set_affinity in proper context
From: Thomas Gleixner <tglx@linutronix.de>
Date: Thu, 14 Jan 2016 08:43:38 +0100

setup_ioapic_dest() calls irqchip->irq_set_affinity() completely
unprotected. That's wrong in several aspects:

 - it triggers a lockdep splat because vector lock is taken with interrupts
   enabled.

 - it opens a race window where irq_set_affinity() can be interrupted and the
   irq chip left in unconsistent state.

The proper calling convention is irq descriptor lock held and interrupts
disabled.

Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
---
 arch/x86/kernel/apic/io_apic.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2521,6 +2521,7 @@ void __init setup_ioapic_dest(void)
 {
 	int pin, ioapic, irq, irq_entry;
 	const struct cpumask *mask;
+	struct irq_desc *desc;
 	struct irq_data *idata;
 	struct irq_chip *chip;
 
@@ -2536,7 +2537,9 @@ void __init setup_ioapic_dest(void)
 		if (irq < 0 || !mp_init_irq_at_boot(ioapic, irq))
 			continue;
 
-		idata = irq_get_irq_data(irq);
+		desc = irq_to_desc(irq);
+		raw_spin_lock_irq(d&desc->lock);
+		idata = irq_desc_get_irq_data(desc);
 
 		/*
 		 * Honour affinities which have been set in early boot
@@ -2550,6 +2553,7 @@ void __init setup_ioapic_dest(void)
 		/* Might be lapic_chip for irq 0 */
 		if (chip->irq_set_affinity)
 			chip->irq_set_affinity(idata, mask, false);
+		raw_spin_unlock_irq(d&desc->lock);
 	}
 }
 #endif

[toc] | [prev] | [next] | [standalone]

#1309167

On Thu, Jan 14, 2016 at 09:24:35AM +0100, Thomas Gleixner wrote:
> On Mon, 4 Jan 2016, Joe Lawrence wrote:
> > No issues running the same PCI device removal and stress tests against
> > the patchset.
> 
> Thanks for testing!
> 
> Though there is yet another long standing bug in that area. Fix below.
> 
> Thanks,
> 
> 	tglx
> 
> 8<--------------------
> 
> Subject: x86/irq: Call chip->irq_set_affinity in proper context
> From: Thomas Gleixner <tglx@linutronix.de>
> Date: Thu, 14 Jan 2016 08:43:38 +0100
> 
> setup_ioapic_dest() calls irqchip->irq_set_affinity() completely
> unprotected. That's wrong in several aspects:
> 
>  - it triggers a lockdep splat because vector lock is taken with interrupts
>    enabled.
> 
>  - it opens a race window where irq_set_affinity() can be interrupted and the
>    irq chip left in unconsistent state.
> 
> The proper calling convention is irq descriptor lock held and interrupts
> disabled.
> 
> Reported-by: Borislav Petkov <bp@alien8.de>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: stable@vger.kernel.org
> ---
>  arch/x86/kernel/apic/io_apic.c |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -2521,6 +2521,7 @@ void __init setup_ioapic_dest(void)
>  {
>  	int pin, ioapic, irq, irq_entry;
>  	const struct cpumask *mask;
> +	struct irq_desc *desc;
>  	struct irq_data *idata;
>  	struct irq_chip *chip;
>  
> @@ -2536,7 +2537,9 @@ void __init setup_ioapic_dest(void)
>  		if (irq < 0 || !mp_init_irq_at_boot(ioapic, irq))
>  			continue;
>  
> -		idata = irq_get_irq_data(irq);
> +		desc = irq_to_desc(irq);
> +		raw_spin_lock_irq(d&desc->lock);

s/d//

> +		idata = irq_desc_get_irq_data(desc);
>  
>  		/*
>  		 * Honour affinities which have been set in early boot
> @@ -2550,6 +2553,7 @@ void __init setup_ioapic_dest(void)
>  		/* Might be lapic_chip for irq 0 */
>  		if (chip->irq_set_affinity)
>  			chip->irq_set_affinity(idata, mask, false);
> +		raw_spin_unlock_irq(d&desc->lock);

s/d//

With those micro-changes:

Tested-by: Borislav Petkov <bp@suse.de>

:-)

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web