linux-kernel - Re: [RFC PATCH] Bug during kexec...not all cpus are stopped

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Oct 2010 14:47:59 -0700
From:	Alok Kataria <akataria@...are.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
	Haren Myneni <hbabu@...ibm.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Daniel Hecht <dhecht@...are.com>,
	"jeremy@...source.com" <jeremy@...source.com>
Subject: Re: [RFC PATCH] Bug during kexec...not all cpus are stopped


On Mon, 2010-10-11 at 14:39 -0700, Vivek Goyal wrote:
> On Mon, Oct 11, 2010 at 12:41:23PM -0700, Alok Kataria wrote:

> > --
> > 
> > x86 smp_ops now has a new op, stop_other_cpus which takes a parameter "wait"
> > this allows the caller to specify if it wants to stop untill all the cpus
> > have processed the stop IPI. This is required specifically for the kexec case
> > where we should wait for all the cpus to be stopped before starting the new
> > kernel.
> 
> > We now wait for the cpus to stop in all cases except for panic/kdump where
> > we expect things to be broken and we are doing our best to make things
> > work anyway.
> 
> I don't think that kdump path uses smp_send_stop().

Right, this should be removed from the patch description.

Belows is the new patch description
----------------------------------------------
x86 smp_ops now has a new op, stop_other_cpus which takes a parameter "wait"
this allows the caller to specify if it wants to stop untill all the cpus
have processed the stop IPI. This is required specifically for the kexec case
where we should wait for all the cpus to be stopped before starting the new
kernel.
We now wait for the cpus to stop in all cases except for panic where
we expect things to be broken and we are doing our best to make things
work anyway.
----------------------------------------------

> 
> IIUC, on x86, we directly send NMI to other cpus.
> 
> native_machine_crash_shutdown()
>   kdump_nmi_shootdown_cpus()
>         nmi_shootdown_cpus()
>            smp_send_nmi_allbutself
>                 apic->send_IPI_allbutself(NMI_VECTOR);
> 
> So above description should be limited to only panic() path.
> 
> On a side note, I am wondering why panic() and kdump path can't share the
> shutdown routine.

The comment in native_stop_other_cpus (native_smp_send_stop earlier)
explains why

        /*
         * Use an own vector here because smp_call_function
         * does lots of things not suitable in a panic situation.
         * On most systems we could also use an NMI here,
         * but there are a few systems around where NMI
         * is problematic so stay with an non NMI for now
         * (this implies we cannot stop CPUs spinning with irq off
         * currently)
         */


Thanks,
Alok
> 
> Vivek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/