[v4,4/4] x86/smp: do not use scratch_cpumask when in interrupt or exception context
diff mbox series

Message ID 20200226121921.28627-5-roger.pau@citrix.com
State New
Headers show
Series
  • x86/smp: fix send_IPI_mask usage of scratch_cpumask
Related show

Commit Message

Roger Pau Monné Feb. 26, 2020, 12:19 p.m. UTC
Using scratch_cpumask in send_IPI_mask is not safe in IRQ or exception
context because it can nest, and hence send_IPI_mask could be
overwriting another user scratch cpumask data when used in such
contexts.

Instead introduce a new cpumask to be used by send_IPI_mask, and
disable interrupts while using it.

Fallback to not using the scratch cpumask (and hence not attemping to
optimize IPI sending by using a shorthand) when in IRQ or exception
context. Note that the scratch cpumask cannot be used when
non-maskable interrupts are being serviced (NMI or #MC) and hence
fallback to not using the shorthand in that case, like it was done
previously.

Fixes: 5500d265a2a8 ('x86/smp: use APIC ALLBUT destination shorthand when possible')
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v3:
 - Do not use a dedicated cpumask, and instead prevent usage when in
   IRQ context.

Changes since v2:
 - Fallback to the previous IPI sending mechanism in #MC or #NMI
   context.

Changes since v1:
 - Don't use the shorthand when in #MC or #NMI context.
---
 xen/arch/x86/smp.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

Comments

Roger Pau Monné Feb. 26, 2020, 12:27 p.m. UTC | #1
On Wed, Feb 26, 2020 at 01:19:21PM +0100, Roger Pau Monne wrote:
> Using scratch_cpumask in send_IPI_mask is not safe in IRQ or exception
> context because it can nest, and hence send_IPI_mask could be
> overwriting another user scratch cpumask data when used in such
> contexts.
> 
> Instead introduce a new cpumask to be used by send_IPI_mask, and
> disable interrupts while using it.
> 
> Fallback to not using the scratch cpumask (and hence not attemping to
> optimize IPI sending by using a shorthand) when in IRQ or exception
> context. Note that the scratch cpumask cannot be used when
> non-maskable interrupts are being serviced (NMI or #MC) and hence
> fallback to not using the shorthand in that case, like it was done
> previously.
> 
> Fixes: 5500d265a2a8 ('x86/smp: use APIC ALLBUT destination shorthand when possible')
> Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> Changes since v3:
>  - Do not use a dedicated cpumask, and instead prevent usage when in
>    IRQ context.
> 
> Changes since v2:
>  - Fallback to the previous IPI sending mechanism in #MC or #NMI
>    context.
> 
> Changes since v1:
>  - Don't use the shorthand when in #MC or #NMI context.
> ---
>  xen/arch/x86/smp.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
> index 55d08c9d52..fa9bfe4d54 100644
> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -69,6 +69,18 @@ void send_IPI_mask(const cpumask_t *mask, int vector)
>      bool cpus_locked = false;
>      cpumask_t *scratch = this_cpu(scratch_cpumask);
>  
> +    if ( in_irq() || in_mce() || in_nmi() )

Sorry, sent and old version, will send 4.1 with this fixed.

Patch
diff mbox series

diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 55d08c9d52..fa9bfe4d54 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -69,6 +69,18 @@  void send_IPI_mask(const cpumask_t *mask, int vector)
     bool cpus_locked = false;
     cpumask_t *scratch = this_cpu(scratch_cpumask);
 
+    if ( in_irq() || in_mce() || in_nmi() )
+    {
+        /*
+         * When in IRQ, NMI or #MC context fallback to the old (and simpler)
+         * IPI sending routine, and avoid doing any performance optimizations
+         * (like using a shorthand) in order to avoid using the scratch
+         * cpumask which cannot be used in interrupt context.
+         */
+        alternative_vcall(genapic.send_IPI_mask, mask, vector);
+        return;
+    }
+
     /*
      * This can only be safely used when no CPU hotplug or unplug operations
      * are taking place, there are no offline CPUs (unless those have been