Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751825AbbKYJqq (ORCPT ); Wed, 25 Nov 2015 04:46:46 -0500 Received: from mail9.hitachi.co.jp ([133.145.228.44]:56797 "EHLO mail9.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750726AbbKYJqm (ORCPT ); Wed, 25 Nov 2015 04:46:42 -0500 From: =?utf-8?B?5rKz5ZCI6Iux5a6PIC8gS0FXQUnvvIxISURFSElSTw==?= To: "'Borislav Petkov'" CC: Jonathan Corbet , Peter Zijlstra , Ingo Molnar , "Eric W. Biederman" , "H. Peter Anvin" , Andrew Morton , Thomas Gleixner , Vivek Goyal , Baoquan He , "linux-doc@vger.kernel.org" , "x86@kernel.org" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Michal Hocko , Ingo Molnar , =?utf-8?B?5bmz5p2+6ZuF5bezIC8gSElSQU1BVFXvvIxNQVNBTUk=?= Subject: RE: [V5 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context Thread-Topic: [V5 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context Thread-Index: AQHRI3eQMDnSwb7qM0y43uYtcLxsUp6qbZyAgAGg9/D//9HtgIAAobHg Date: Wed, 25 Nov 2015 09:46:37 +0000 Message-ID: <04EAB7311EE43145B2D3536183D1A84454A2B929@GSjpTKYDCembx31.service.hitachi.net> References: <20151120093641.4285.97253.stgit@softrs> <20151120093646.4285.62259.stgit@softrs> <20151124104853.GC3785@pd.tnic> <04EAB7311EE43145B2D3536183D1A84454A2A425@GSjpTKYDCembx31.service.hitachi.net> <20151125085620.GA29499@pd.tnic> In-Reply-To: <20151125085620.GA29499@pd.tnic> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.198.220.44] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id tAP9kqPc027028 Content-Length: 3676 Lines: 94 > On Wed, Nov 25, 2015 at 05:51:59AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > > `Infinite loop in NMI context' can happen: > > > > > > > > a. when a cpu panics on NMI while another cpu is processing panic > > > > b. when a cpu received an external or unknown NMI while another > > > > cpu is processing panic on NMI > > > > > > > > In the case of a, it loops in panic_smp_self_stop(). In the case > > > > of b, it loops in raw_spin_lock() of nmi_reason_lock. > > > > > > Please describe those two cases more verbosely - it takes slow people > > > like me a while to figure out what exactly can happen. > > > > a. when a cpu panics on NMI while another cpu is processing panic > > Ex. > > CPU 0 CPU 1 > > ================= ================= > > panic() > > panic_cpu <-- 0 > > check panic_cpu > > crash_kexec() > > receive an unknown NMI > > unknown_nmi_error() > > nmi_panic() > > panic() > > check panic_cpu > > panic_smp_self_stop() > > infinite loop in NMI context > > > > b. when a cpu received an external or unknown NMI while another > > cpu is processing panic on NMI > > Ex. > > CPU 0 CPU 1 > > ====================== ================== > > receive an unknown NMI > > unknown_nmi_error() > > nmi_panic() receive an unknown NMI > > panic_cpu <-- 0 unknown_nmi_error() > > panic() nmi_panic() > > check panic_cpu panic > > crash_kexec() check panic_cpu > > panic_smp_self_stop() > > infinite loop in NMI context > > Ok, that's what I saw too, thanks for confirming. > > But please write those examples with the *old* code in the commit > message, i.e. without panic_cpu and nmi_panic() which you're adding. Does *old* code mean the code without this patch *series* ? panic_cpu and nmi_panic() are introduced by PATCH 1/4, not this patch. > Basically, you want to structure your commit message this way: > > This is the problem the current code has: ... > > But we need to do this: ... > > We fix it by doing that: ... Good suggestion! I'll revise a bit with following your comment. > > > > + * directly. This function is used when we have already been in NMI handler. > > > > + */ > > > > +void poll_crash_ipi_and_callback(struct pt_regs *regs) > > > > > > Why "poll"? We won't return from crash_nmi_callback() if we're not the > > > crashing CPU. > > > > This function polls that crash IPI has been issued by checking > > crash_ipi_done, then invokes the callback. This is different > > from so-called "poll" functions. Do you have some good name? > > Maybe something as simple as "run_crash_callback"? I prefer this, but we might want to add some more prefix or suffix. For example, "conditionally_run_crash_nmi_callback". > Or since we're calling it from other places, maybe add the "crash" > prefix: > > while (!raw_spin_trylock(&nmi_reason_lock)) > crash_run_callback(regs); > > Looks even better to me in code context. :) Thanks for your deep review! -- Hidehiro Kawai Hitachi, Ltd. Research & Development Group ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?