On Wed, 7 Aug 2019, Pingfan Liu wrote: > On Wed, Aug 07, 2019 at 11:00:41AM +0800, Dave Young wrote: > > Add Tony and Xunlei in cc. > > On 08/05/19 at 04:58pm, Pingfan Liu wrote: > > > This series include two related groups: > > > [1-3/4]: protect nr_cpus from rebooting by broadcast mce > > > [4/4]: improve "kexec -l" robustness against broadcast mce > > > > > > When I tried to fix [1], Thomas raised concern about the nr_cpus' vulnerability > > > to unexpected rebooting by broadcast mce. After analysis, I think only the > > > following first case suffers from the rebooting by broadcast mce. [1-3/4] aims > > > to fix that issue. > > > > I did not understand and read the MCE details, but we previously had a > > MCE problem, Xunlei fixed in below commit: > > commit 5bc329503e8191c91c4c40836f062ef771d8ba83 > > Author: Xunlei Pang <xlpang@xxxxxxxxxx> > > Date: Mon Mar 13 10:50:19 2017 +0100 > > > > x86/mce: Handle broadcasted MCE gracefully with kexec > > > > I wonder if this is same issue or not. Also the old discussion is in > > below thread: > > https://lore.kernel.org/patchwork/patch/753530/ > > > > Tony raised similar questions, but I'm not sure if it is still a problem > > or it has been fixed. > > > > Xunlei's patch is the precondition of the stability for the case 2: boot > up by "kexec -p nr_cpus=" Correct. The only dangerous issue which is then left is that an MCE hits _before_ all CPUs have CR.MCE=1 set. That's a general issue also for cold boot. Thanks to the brilliant hardware design, all we can do is pray.... > For case1/3, extra effort is needed. > > Thanks, > Pingfan > > > > > > *** Back ground *** > > > > > > On x86 it's required to have all logical CPUs set CR4.MCE=1. Otherwise, a > > > broadcast MCE observing CR4.MCE=0b on any core will shutdown the machine. Pingfan, please trim your replies and remove the useless gunk after your answer. Thanks, tglx _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
