From: Borislav Petkov <bp@alien8.de> To: "河合英宏 / KAWAI,HIDEHIRO" <hidehiro.kawai.ez@hitachi.com> Cc: "Jonathan Corbet" <corbet@lwn.net>, "Peter Zijlstra" <peterz@infradead.org>, "Ingo Molnar" <mingo@kernel.org>, "Eric W. Biederman" <ebiederm@xmission.com>, "H. Peter Anvin" <hpa@zytor.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Thomas Gleixner" <tglx@linutronix.de>, "Vivek Goyal" <vgoyal@redhat.com>, "Baoquan He" <bhe@redhat.com>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, "x86@kernel.org" <x86@kernel.org>, "kexec@lists.infradead.org" <kexec@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "Michal Hocko" <mhocko@kernel.org>, "平松雅巳 / HIRAMATU,MASAMI" <masami.hiramatsu.pt@hitachi.com> Subject: Re: [V5 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly Date: Thu, 3 Dec 2015 13:22:20 +0100 [thread overview] Message-ID: <20151203122220.GA3213@pd.tnic> (raw) In-Reply-To: <04EAB7311EE43145B2D3536183D1A84454A3DF12@GSjpTKYDCembx31.service.hitachi.net> On Thu, Dec 03, 2015 at 11:29:21AM +0000, 河合英宏 / KAWAI,HIDEHIRO wrote: > I was arguing about the case of oops_end --> crash_kexec > --> return from crash_kexec because of !kexec_crash_image --> > panic. Aha. > In the case of panic --> __crash_kexec, __crash_kexec is called > only once, so we don't need to check the return value of __crash_kexec > as you suggested. So I thought you stated about crash_kexec --> panic > case. No, I meant the other way around. > I also mentioned !kexec_crash_image case... I must've missed it. > No. The first CPU calls panic, and then it calls __crash_kexec. > Because of !kexec_crash_image, it returns from __crash_kexec and > continues to the panic procedure. At the same time, another CPU > tries to call panic(), but it doesn't run the panic procedure; > panic_cpu prevents the second CPU from running it. > > This means __crash_kexec is called only once even if we don't > check the return value of __crash_kexec. I think we're on the same page, even if we express it differently - the other CPUs entering panic() will loop in panic_smp_self_stop() so they won't reach __crash_kexec(). > (Please note that crash_kexec can be called multiple times in the > case of oops_end() --> crash_kexec().) Right, and that was the case that was bugging me - calling into crash_kexec() on multiple CPUs but it is a trylock and a pointer test - I guess that's diminishingly small overhead to care. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de> To: "河合英宏 / KAWAI,HIDEHIRO" <hidehiro.kawai.ez@hitachi.com> Cc: "x86@kernel.org" <x86@kernel.org>, "Baoquan He" <bhe@redhat.com>, "Jonathan Corbet" <corbet@lwn.net>, "Peter Zijlstra" <peterz@infradead.org>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, "kexec@lists.infradead.org" <kexec@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "Michal Hocko" <mhocko@kernel.org>, "Thomas Gleixner" <tglx@linutronix.de>, "Eric W. Biederman" <ebiederm@xmission.com>, "H. Peter Anvin" <hpa@zytor.com>, "平松雅巳 / HIRAMATU,MASAMI" <masami.hiramatsu.pt@hitachi.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Ingo Molnar" <mingo@kernel.org>, "Vivek Goyal" <vgoyal@redhat.com> Subject: Re: [V5 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly Date: Thu, 3 Dec 2015 13:22:20 +0100 [thread overview] Message-ID: <20151203122220.GA3213@pd.tnic> (raw) In-Reply-To: <04EAB7311EE43145B2D3536183D1A84454A3DF12@GSjpTKYDCembx31.service.hitachi.net> On Thu, Dec 03, 2015 at 11:29:21AM +0000, 河合英宏 / KAWAI,HIDEHIRO wrote: > I was arguing about the case of oops_end --> crash_kexec > --> return from crash_kexec because of !kexec_crash_image --> > panic. Aha. > In the case of panic --> __crash_kexec, __crash_kexec is called > only once, so we don't need to check the return value of __crash_kexec > as you suggested. So I thought you stated about crash_kexec --> panic > case. No, I meant the other way around. > I also mentioned !kexec_crash_image case... I must've missed it. > No. The first CPU calls panic, and then it calls __crash_kexec. > Because of !kexec_crash_image, it returns from __crash_kexec and > continues to the panic procedure. At the same time, another CPU > tries to call panic(), but it doesn't run the panic procedure; > panic_cpu prevents the second CPU from running it. > > This means __crash_kexec is called only once even if we don't > check the return value of __crash_kexec. I think we're on the same page, even if we express it differently - the other CPUs entering panic() will loop in panic_smp_self_stop() so they won't reach __crash_kexec(). > (Please note that crash_kexec can be called multiple times in the > case of oops_end() --> crash_kexec().) Right, and that was the case that was bugging me - calling into crash_kexec() on multiple CPUs but it is a trylock and a pointer test - I guess that's diminishingly small overhead to care. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2015-12-03 12:22 UTC|newest] Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-11-20 9:36 [V5 PATCH 0/4] Fix race issues among panic, NMI and crash_kexec Hidehiro Kawai 2015-11-20 9:36 ` Hidehiro Kawai 2015-11-20 9:36 ` [V5 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI Hidehiro Kawai 2015-11-20 9:36 ` Hidehiro Kawai 2015-11-23 18:49 ` Borislav Petkov 2015-11-23 18:49 ` Borislav Petkov 2015-11-24 4:06 ` 河合英宏 / KAWAI,HIDEHIRO 2015-11-24 4:06 ` 河合英宏 / KAWAI,HIDEHIRO 2015-11-24 12:45 ` Michal Hocko 2015-11-24 12:45 ` Michal Hocko 2015-11-24 15:05 ` Steven Rostedt 2015-11-24 15:05 ` Steven Rostedt 2015-11-24 15:12 ` Steven Rostedt 2015-11-24 15:12 ` Steven Rostedt 2015-11-24 20:27 ` Michal Hocko 2015-11-24 20:27 ` Michal Hocko 2015-11-24 20:45 ` Steven Rostedt 2015-11-24 20:45 ` Steven Rostedt 2015-11-20 9:36 ` [V5 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context Hidehiro Kawai 2015-11-20 9:36 ` Hidehiro Kawai 2015-11-24 10:48 ` Borislav Petkov 2015-11-24 10:48 ` Borislav Petkov 2015-11-24 19:37 ` Steven Rostedt 2015-11-24 19:37 ` Steven Rostedt 2015-11-24 20:16 ` Borislav Petkov 2015-11-24 20:16 ` Borislav Petkov 2015-11-25 5:57 ` 河合英宏 / KAWAI,HIDEHIRO 2015-11-25 5:57 ` 河合英宏 / KAWAI,HIDEHIRO 2015-11-25 5:51 ` 河合英宏 / KAWAI,HIDEHIRO 2015-11-25 5:51 ` 河合英宏 / KAWAI,HIDEHIRO 2015-11-25 8:56 ` Borislav Petkov 2015-11-25 8:56 ` Borislav Petkov 2015-11-25 9:46 ` 河合英宏 / KAWAI,HIDEHIRO 2015-11-25 9:46 ` 河合英宏 / KAWAI,HIDEHIRO 2015-11-25 9:57 ` Borislav Petkov 2015-11-25 9:57 ` Borislav Petkov 2015-11-25 15:11 ` 河合英宏 / KAWAI,HIDEHIRO 2015-11-25 15:11 ` 河合英宏 / KAWAI,HIDEHIRO 2015-11-24 12:58 ` Michal Hocko 2015-11-24 12:58 ` Michal Hocko 2015-12-03 2:23 ` 河合英宏 / KAWAI,HIDEHIRO 2015-12-03 2:23 ` 河合英宏 / KAWAI,HIDEHIRO 2015-11-20 9:36 ` [V5 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly Hidehiro Kawai 2015-11-20 9:36 ` Hidehiro Kawai 2015-11-24 13:05 ` Michal Hocko 2015-11-24 13:05 ` Michal Hocko 2015-11-24 20:35 ` Steven Rostedt 2015-11-24 20:35 ` Steven Rostedt 2015-11-25 6:28 ` 河合英宏 / KAWAI,HIDEHIRO 2015-11-25 6:28 ` 河合英宏 / KAWAI,HIDEHIRO 2015-11-25 9:54 ` Borislav Petkov 2015-11-25 9:54 ` Borislav Petkov 2015-12-02 11:57 ` 河合英宏 / KAWAI,HIDEHIRO 2015-12-02 11:57 ` 河合英宏 / KAWAI,HIDEHIRO 2015-12-02 15:40 ` Borislav Petkov 2015-12-02 15:40 ` Borislav Petkov 2015-12-03 2:01 ` 河合英宏 / KAWAI,HIDEHIRO 2015-12-03 2:01 ` 河合英宏 / KAWAI,HIDEHIRO 2015-12-03 9:35 ` Borislav Petkov 2015-12-03 9:35 ` Borislav Petkov 2015-12-03 11:29 ` 河合英宏 / KAWAI,HIDEHIRO 2015-12-03 11:29 ` 河合英宏 / KAWAI,HIDEHIRO 2015-12-03 12:22 ` Borislav Petkov [this message] 2015-12-03 12:22 ` Borislav Petkov 2015-11-20 9:36 ` [V5 PATCH 4/4] x86/apic: Introduce apic_extnmi boot option Hidehiro Kawai 2015-11-20 9:36 ` Hidehiro Kawai 2015-11-25 11:49 ` Borislav Petkov 2015-11-25 11:49 ` Borislav Petkov 2015-11-25 15:29 ` 河合英宏 / KAWAI,HIDEHIRO 2015-11-25 15:29 ` 河合英宏 / KAWAI,HIDEHIRO
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20151203122220.GA3213@pd.tnic \ --to=bp@alien8.de \ --cc=akpm@linux-foundation.org \ --cc=bhe@redhat.com \ --cc=corbet@lwn.net \ --cc=ebiederm@xmission.com \ --cc=hidehiro.kawai.ez@hitachi.com \ --cc=hpa@zytor.com \ --cc=kexec@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=masami.hiramatsu.pt@hitachi.com \ --cc=mhocko@kernel.org \ --cc=mingo@kernel.org \ --cc=peterz@infradead.org \ --cc=tglx@linutronix.de \ --cc=vgoyal@redhat.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.