[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 5/6] x86/smp: use a dedicated scratch cpumask in send_IPI_mask
On Tue, Feb 18, 2020 at 11:35:37AM +0000, Andrew Cooper wrote: > > > On 18/02/2020 11:22, Roger Pau Monné wrote: > > On Tue, Feb 18, 2020 at 11:21:12AM +0000, Andrew Cooper wrote: > >> On 18/02/2020 11:10, Roger Pau Monné wrote: > >>> On Tue, Feb 18, 2020 at 10:53:45AM +0000, Andrew Cooper wrote: > >>>> On 17/02/2020 18:43, Roger Pau Monne wrote: > >>>>> @@ -67,7 +68,20 @@ static void send_IPI_shortcut(unsigned int shortcut, > >>>>> int vector, > >>>>> void send_IPI_mask(const cpumask_t *mask, int vector) > >>>>> { > >>>>> bool cpus_locked = false; > >>>>> - cpumask_t *scratch = this_cpu(scratch_cpumask); > >>>>> + cpumask_t *scratch = this_cpu(send_ipi_cpumask); > >>>>> + unsigned long flags; > >>>>> + > >>>>> + if ( in_mc() || in_nmi() ) > >>>>> + { > >>>>> + /* > >>>>> + * When in #MC or #MNI context Xen cannot use the per-CPU > >>>>> scratch mask > >>>>> + * because we have no way to avoid reentry, so do not use the > >>>>> APIC > >>>>> + * shorthand. > >>>>> + */ > >>>>> + alternative_vcall(genapic.send_IPI_mask, mask, vector); > >>>>> + return; > >>>> The set of things you can safely do in an NMI/MCE handler is small, and > >>>> does not include sending IPIs. (In reality, if you're using x2apic, it > >>>> is safe to send an IPI because there is no risk of clobbering ICR2 > >>>> behind your outer context's back). > >>>> > >>>> However, if we escalate from NMI/MCE context into crash context, then > >>>> anything goes. In reality, we only ever send NMIs from the crash path, > >>>> and that is not permitted to use a shorthand, making this code dead. > >>> This was requested by Jan, as safety measure > >> That may be, but it doesn't mean it is correct. If execution ever > >> enters this function in NMI/MCE context, there is a real, > >> state-corrupting bug, higher up the call stack. > > Ack, then I guess we should just BUG() here if ever called from #NMI > > or #MC context? > > Well. There is a reason I suggested removing it, and not using BUG(). > > If NMI/MCE context escalates to crash context, we do need to send NMIs. > It won't be this function specifically, but it will be part of the > general IPI infrastructure. > > We definitely don't want to get into the game of trying to clobber each > of the state variables, so the only thing throwing BUG()'s around in > this area will do is make the crash path more fragile. I see, panicking in such context will just clobber the previous crash happened in NMI/MC context. So you would rather keep the current version of falling back to the usage of the non-shorthand IPI sending routine instead of panicking? What about: if ( in_mc() || in_nmi() ) { /* * When in #MC or #MNI context Xen cannot use the per-CPU scratch mask * because we have no way to avoid reentry, so do not use the APIC * shorthand. The only IPI that should be sent from such context * is a #NMI to shutdown the system in case of a crash. */ if ( vector == APIC_DM_NMI ) alternative_vcall(genapic.send_IPI_mask, mask, vector); else BUG(); return; } Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |