[Xen-devel] [PATCH v4 0/4] x86/smp: fix send_IPI_mask usage of scratch_cpumask

[Xen-devel] [PATCH v4 0/4] x86/smp: fix send_IPI_mask usage of scratch_cpumask

[Roger Pau Monne]

Hello,

Commit:

5500d265a2a8fa63d60c08beb549de8ec82ff7a5
x86/smp: use APIC ALLBUT destination shorthand when possible

Introduced a bogus usage of the scratch cpumask: it was used in a
function that could be called from interrupt context, and hence using
the scratch cpumask there is not safe. Patch #4 is a fix for that usage,
together with also preventing the usage of any per-CPU variables when
send_IPI_mask is called from #MC or NMI context. Previous patches are
preparatory changes.

Thanks, Roger.

Roger Pau Monne (4):
  x86: introduce a nmi_count tracking variable
  x86: track when in NMI context
  x86: track when in #MC context
  x86/smp: do not use scratch_cpumask when in interrupt or exception
    context

 xen/arch/x86/cpu/mcheck/mce.c |  2 ++
 xen/arch/x86/nmi.c            | 11 +++++------
 xen/arch/x86/smp.c            | 12 ++++++++++++
 xen/arch/x86/traps.c          | 10 +++++++++-
 xen/include/asm-x86/hardirq.h | 13 ++++++++++++-
 xen/include/asm-x86/nmi.h     |  2 ++
 xen/include/xen/irq_cpustat.h |  1 -
 7 files changed, 42 insertions(+), 9 deletions(-)

-- 
2.25.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v4 1/4] x86: introduce a nmi_count tracking variable

[Roger Pau Monne]

This is modeled after the irq_count variable, and is used to account
for all the NMIs handled by the system.

This will allow to repurpose the nmi_count() helper so it can be used
in a similar manner as local_irq_count(): account for the NMIs
currently in service.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v3:
 - Remove nmi_count macro and __nmi_count field in irq_cpustat_t.
---
 xen/arch/x86/nmi.c            | 11 +++++------
 xen/arch/x86/traps.c          |  4 +++-
 xen/include/asm-x86/hardirq.h |  1 -
 xen/include/asm-x86/nmi.h     |  2 ++
 xen/include/xen/irq_cpustat.h |  1 -
 5 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index a69b91a924..c3f92ed231 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -151,15 +151,14 @@ int nmi_active;
 
 static void __init wait_for_nmis(void *p)
 {
-    unsigned int cpu = smp_processor_id();
-    unsigned int start_count = nmi_count(cpu);
+    unsigned int start_count = this_cpu(nmi_count);
     unsigned long ticks = 10 * 1000 * cpu_khz / nmi_hz;
     unsigned long s, e;
 
     s = rdtsc();
     do {
         cpu_relax();
-        if ( nmi_count(cpu) >= start_count + 2 )
+        if ( this_cpu(nmi_count) >= start_count + 2 )
             break;
         e = rdtsc();
     } while( e - s < ticks );
@@ -177,7 +176,7 @@ void __init check_nmi_watchdog(void)
     printk("Testing NMI watchdog on all CPUs:");
 
     for_each_online_cpu ( cpu )
-        prev_nmi_count[cpu] = nmi_count(cpu);
+        prev_nmi_count[cpu] = per_cpu(nmi_count, cpu);
 
     /*
      * Wait at most 10 ticks for 2 watchdog NMIs on each CPU.
@@ -188,7 +187,7 @@ void __init check_nmi_watchdog(void)
 
     for_each_online_cpu ( cpu )
     {
-        if ( nmi_count(cpu) - prev_nmi_count[cpu] < 2 )
+        if ( per_cpu(nmi_count, cpu) - prev_nmi_count[cpu] < 2 )
         {
             printk(" %d", cpu);
             ok = false;
@@ -593,7 +592,7 @@ static void do_nmi_stats(unsigned char key)
 
     printk("CPU\tNMI\n");
     for_each_online_cpu ( cpu )
-        printk("%3u\t%3u\n", cpu, nmi_count(cpu));
+        printk("%3u\t%3u\n", cpu, per_cpu(nmi_count, cpu));
 
     if ( !hardware_domain || !(v = domain_vcpu(hardware_domain, 0)) )
         return;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 56067f85d1..3dbc66bb64 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1683,13 +1683,15 @@ static int dummy_nmi_callback(const struct cpu_user_regs *regs, int cpu)
 
 static nmi_callback_t *nmi_callback = dummy_nmi_callback;
 
+DEFINE_PER_CPU(unsigned int, nmi_count);
+
 void do_nmi(const struct cpu_user_regs *regs)
 {
     unsigned int cpu = smp_processor_id();
     unsigned char reason = 0;
     bool handle_unknown = false;
 
-    ++nmi_count(cpu);
+    this_cpu(nmi_count)++;
 
     if ( nmi_callback(regs, cpu) )
         return;
diff --git a/xen/include/asm-x86/hardirq.h b/xen/include/asm-x86/hardirq.h
index 34e1b49260..802f91cfdf 100644
--- a/xen/include/asm-x86/hardirq.h
+++ b/xen/include/asm-x86/hardirq.h
@@ -7,7 +7,6 @@
 typedef struct {
 	unsigned int __softirq_pending;
 	unsigned int __local_irq_count;
-	unsigned int __nmi_count;
 	bool_t __mwait_wakeup;
 } __cacheline_aligned irq_cpustat_t;
 
diff --git a/xen/include/asm-x86/nmi.h b/xen/include/asm-x86/nmi.h
index f9dfca6afb..a288f02a50 100644
--- a/xen/include/asm-x86/nmi.h
+++ b/xen/include/asm-x86/nmi.h
@@ -31,5 +31,7 @@ nmi_callback_t *set_nmi_callback(nmi_callback_t *callback);
  * Remove the handler previously set.
  */
 void unset_nmi_callback(void);
+
+DECLARE_PER_CPU(unsigned int, nmi_count);
  
 #endif /* ASM_NMI_H */
diff --git a/xen/include/xen/irq_cpustat.h b/xen/include/xen/irq_cpustat.h
index 73629f6ec8..b9629f25c2 100644
--- a/xen/include/xen/irq_cpustat.h
+++ b/xen/include/xen/irq_cpustat.h
@@ -24,7 +24,6 @@ extern irq_cpustat_t irq_stat[];
   /* arch independent irq_stat fields */
 #define softirq_pending(cpu)	__IRQ_STAT((cpu), __softirq_pending)
 #define local_irq_count(cpu)	__IRQ_STAT((cpu), __local_irq_count)
-#define nmi_count(cpu)		__IRQ_STAT((cpu), __nmi_count)
 #define mwait_wakeup(cpu)	__IRQ_STAT((cpu), __mwait_wakeup)
 
 #endif	/* __irq_cpustat_h */
-- 
2.25.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 1/4] x86: introduce a nmi_count tracking variable

[Jan Beulich]

On 26.02.2020 13:19, Roger Pau Monne wrote:
> This is modeled after the irq_count variable, and is used to account
> for all the NMIs handled by the system.
> 
> This will allow to repurpose the nmi_count() helper so it can be used
> in a similar manner as local_irq_count(): account for the NMIs
> currently in service.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v4 2/4] x86: track when in NMI context

[Roger Pau Monne]

Add helpers to track when running in NMI handler context. This is
modeled after the in_irq helpers.

The SDM states that no NMI can be delivered while handling a NMI
until the processor has executed an iret instruction. It's possible
however that another fault is received while handling the NMI (a #MC
for example), and thus the iret from that fault would allow further
NMIs to be injected while still processing the previous one, and
hence an integer is needed in order to keep track of in service NMIs.
The added macros only track when the execution context is in the NMI
handler, but that doesn't mean NMIs are blocked for the reasons listed
above.

Note that there are no users of in_nmi_handler() introduced by the
change, further users will be added by followup changes.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v3:
 - Rename to in_nmi_context.
 - Drop parentheses around cpu in nmi_count.

Changes since v2:
 - Use an integer instead of a boolean to keep track of in service
   #NMIs.
 - Move nmi_count into x86 specific header.
 - Drop leading underscores from __nmi_count field.
---
 xen/arch/x86/traps.c          | 6 ++++++
 xen/include/asm-x86/hardirq.h | 6 ++++++
 2 files changed, 12 insertions(+)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 3dbc66bb64..f4f2c13ae9 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1692,9 +1692,13 @@ void do_nmi(const struct cpu_user_regs *regs)
     bool handle_unknown = false;
 
     this_cpu(nmi_count)++;
+    nmi_enter();
 
     if ( nmi_callback(regs, cpu) )
+    {
+        nmi_exit();
         return;
+    }
 
     /*
      * Accessing port 0x61 may trap to SMM which has been actually
@@ -1720,6 +1724,8 @@ void do_nmi(const struct cpu_user_regs *regs)
         if ( !(reason & 0xc0) && handle_unknown )
             unknown_nmi_error(regs, reason);
     }
+
+    nmi_exit();
 }
 
 nmi_callback_t *set_nmi_callback(nmi_callback_t *callback)
diff --git a/xen/include/asm-x86/hardirq.h b/xen/include/asm-x86/hardirq.h
index 802f91cfdf..069e48fce9 100644
--- a/xen/include/asm-x86/hardirq.h
+++ b/xen/include/asm-x86/hardirq.h
@@ -7,6 +7,7 @@
 typedef struct {
 	unsigned int __softirq_pending;
 	unsigned int __local_irq_count;
+	unsigned int nmi_count;
 	bool_t __mwait_wakeup;
 } __cacheline_aligned irq_cpustat_t;
 
@@ -17,6 +18,11 @@ typedef struct {
 #define irq_enter()	(local_irq_count(smp_processor_id())++)
 #define irq_exit()	(local_irq_count(smp_processor_id())--)
 
+#define nmi_count(cpu)		__IRQ_STAT(cpu, nmi_count)
+#define in_nmi_handler()	(nmi_count(smp_processor_id()) != 0)
+#define nmi_enter()		(nmi_count(smp_processor_id())++)
+#define nmi_exit()		(nmi_count(smp_processor_id())--)
+
 void ack_bad_irq(unsigned int irq);
 
 extern void apic_intr_init(void);
-- 
2.25.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 2/4] x86: track when in NMI context

[Jan Beulich]

On 26.02.2020 13:19, Roger Pau Monne wrote:
> Add helpers to track when running in NMI handler context. This is
> modeled after the in_irq helpers.
> 
> The SDM states that no NMI can be delivered while handling a NMI
> until the processor has executed an iret instruction. It's possible
> however that another fault is received while handling the NMI (a #MC
> for example), and thus the iret from that fault would allow further
> NMIs to be injected while still processing the previous one, and
> hence an integer is needed in order to keep track of in service NMIs.
> The added macros only track when the execution context is in the NMI
> handler, but that doesn't mean NMIs are blocked for the reasons listed
> above.
> 
> Note that there are no users of in_nmi_handler() introduced by the
> change, further users will be added by followup changes.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v4 3/4] x86: track when in #MC context

[Roger Pau Monne]

Add helpers to track when executing in #MC handler context. This is
modeled after the in_irq helpers.

Note that there are no users of in_mce_handler() introduced by the
change, further users will be added by followup changes.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v3:
 - Rename to in_mce_handler.
 - Drop parentheses around cpu in macro.

Changes since v2:
 - Move definition of mc_count to x86 hardirq.h.
---
 xen/arch/x86/cpu/mcheck/mce.c | 2 ++
 xen/include/asm-x86/hardirq.h | 6 ++++++
 2 files changed, 8 insertions(+)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index d61e582af3..e5bd4f542c 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -93,7 +93,9 @@ void x86_mce_vector_register(x86_mce_vector_t hdlr)
 
 void do_machine_check(const struct cpu_user_regs *regs)
 {
+    mce_enter();
     _machine_check_vector(regs);
+    mce_exit();
 }
 
 /*
diff --git a/xen/include/asm-x86/hardirq.h b/xen/include/asm-x86/hardirq.h
index 069e48fce9..276e3419d7 100644
--- a/xen/include/asm-x86/hardirq.h
+++ b/xen/include/asm-x86/hardirq.h
@@ -8,6 +8,7 @@ typedef struct {
 	unsigned int __softirq_pending;
 	unsigned int __local_irq_count;
 	unsigned int nmi_count;
+	unsigned int mce_count;
 	bool_t __mwait_wakeup;
 } __cacheline_aligned irq_cpustat_t;
 
@@ -23,6 +24,11 @@ typedef struct {
 #define nmi_enter()		(nmi_count(smp_processor_id())++)
 #define nmi_exit()		(nmi_count(smp_processor_id())--)
 
+#define mce_count(cpu)		__IRQ_STAT(cpu, mce_count)
+#define in_mce_handler()	(mce_count(smp_processor_id()) != 0)
+#define mce_enter()		(mce_count(smp_processor_id())++)
+#define mce_exit()		(mce_count(smp_processor_id())--)
+
 void ack_bad_irq(unsigned int irq);
 
 extern void apic_intr_init(void);
-- 
2.25.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 3/4] x86: track when in #MC context

[Jan Beulich]

On 26.02.2020 13:19, Roger Pau Monne wrote:
> Add helpers to track when executing in #MC handler context. This is
> modeled after the in_irq helpers.
> 
> Note that there are no users of in_mce_handler() introduced by the
> change, further users will be added by followup changes.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

FTR I'm not finally certain this doesn't go a little too far.
#MC handling paths have to be very careful anyway in what they
call or do.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v4 4/4] x86/smp: do not use scratch_cpumask when in interrupt or exception context

[Roger Pau Monne]

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() )
+    {
+        /*
+         * 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
-- 
2.25.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 4/4] x86/smp: do not use scratch_cpumask when in interrupt or exception context

[Roger Pau Monné]

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v5 4/4] x86/smp: do not use scratch_cpumask when in interrupt or exception context

[Roger Pau Monne]

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 v4:
 - Add _handler suffix to in_nmi/in_mce calls.

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..0461812cf6 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_handler() || in_nmi_handler() )
+    {
+        /*
+         * 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
-- 
2.25.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 4/4] x86/smp: do not use scratch_cpumask when in interrupt or exception context

[Jan Beulich]

On 26.02.2020 13:38, 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.

With this now apparently stale sentence dropped (easily done
while committing)

> 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>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 4/4] x86/smp: do not use scratch_cpumask when in interrupt or exception context

[Roger Pau Monné]

On Wed, Feb 26, 2020 at 02:10:44PM +0100, Jan Beulich wrote:
> On 26.02.2020 13:38, 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.
> 
> With this now apparently stale sentence dropped (easily done
> while committing)

Uh, I thought I fixed the commit message, but looks like I missed that
bit.

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel