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]
Message-ID: <20131106094848.GB2425@dhcp-16-105.nay.redhat.com>
Date:	Wed, 6 Nov 2013 17:48:48 +0800
From:	Baoquan He <bhe@...hat.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	mwhitehe@...hat.com, x86@...nel.org, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, davej@...oraproject.org,
	mingo@...hat.com, holt@....com, hpa@...or.com,
	rmk+kernel@....linux.org.uk, tglx@...utronix.de,
	akpm@...ux-foundation.org, chaowang@...hat.com
Subject: Re: [PATCH] x86: make reboot task only run on the appropriate
 processor

On 11/05/13 at 03:28pm, Vivek Goyal wrote:
> On Tue, Nov 05, 2013 at 05:16:07PM +0800, Baoquan He wrote:
> > Currently system always reboot after below message when execute "kexec -e".
> > 
> > [    0.572119] smpboot: Booting Node   0, Processors  #   1 OK
> > 
> 
> So is it same problem were we reboot on non-boot cpu and sending INIT
> to boot cpu in second kernel brings down the machine?

They are different. Kdump hang when crash didn't happen on bsp, then
multiple CPUs are brought up, the bsp will go through the boot strap
code after INIT IPI message received. However in this case, executing
"kexec -e" will make system reboot and bring up only 1 CPU, then go back
to BIOS and reboot. 

In kdump, nmi is sent to shutdown other CPUs. In this shutdown, cleanup
is done and finally processor is halt. And if crash didn't happen on
bsp, during system startup INIT sent to bsp will cause system hang.

However, in kexec reboot, a REBOOT_VECTOR interrupt is sent to all other
CPUs. In commit 4ef702c10b5df18ab04921fc252c26421d4d6c75, Andi imported
this IPI interrupt vector. Andi said it has been given the highest
priority.

It's still not very clear why this happened without that code block.
Seems interrupt disable is very doubtful.

> 
> I think for x86, it makes sense to reboot on boot cpu.
> 
> Thanks
> Vivek
> 

> _______________________________________________
> kexec mailing list
> kexec@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ