Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758142AbbLCCXj (ORCPT ); Wed, 2 Dec 2015 21:23:39 -0500 Received: from mail4.hitachi.co.jp ([133.145.228.5]:60437 "EHLO mail4.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757803AbbLCCXh (ORCPT ); Wed, 2 Dec 2015 21:23:37 -0500 From: =?utf-8?B?5rKz5ZCI6Iux5a6PIC8gS0FXQUnvvIxISURFSElSTw==?= To: =?utf-8?B?5rKz5ZCI6Iux5a6PIC8gS0FXQUnvvIxISURFSElSTw==?= , Jonathan Corbet , "Peter Zijlstra" , Ingo Molnar , "Eric W. Biederman" , "H. Peter Anvin" , "Andrew Morton" , Thomas Gleixner , Vivek Goyal CC: Baoquan He , "linux-doc@vger.kernel.org" , "x86@kernel.org" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Michal Hocko , Ingo Molnar , Borislav Petkov , =?utf-8?B?5bmz5p2+6ZuF5bezIC8gSElSQU1BVFXvvIxNQVNBTUk=?= , "'Steven Rostedt'" 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: AQHRI3eQMDnSwb7qM0y43uYtcLxsUp64mJtw Date: Thu, 3 Dec 2015 02:23:32 +0000 Message-ID: <04EAB7311EE43145B2D3536183D1A84454A3CDD3@GSjpTKYDCembx31.service.hitachi.net> References: <20151120093641.4285.97253.stgit@softrs> <20151120093646.4285.62259.stgit@softrs> In-Reply-To: <20151120093646.4285.62259.stgit@softrs> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.198.219.54] 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 tB32NgTK010948 Content-Length: 1203 Lines: 36 > @@ -357,7 +358,15 @@ static void default_do_nmi(struct pt_regs *regs) > } > > /* Non-CPU-specific NMI: NMI sources can be processed on any CPU */ > - raw_spin_lock(&nmi_reason_lock); > + > + /* > + * Another CPU may be processing panic routines with holding > + * nmi_reason_lock. Check IPI issuance from the panicking CPU > + * and call the callback directly. > + */ > + while (!raw_spin_trylock(&nmi_reason_lock)) > + poll_crash_ipi_and_callback(regs); > + > reason = x86_platform.get_nmi_reason(); I noticed this logic is unneeded until applying PATCH 4/4. Currently, unknown NMI can be broadcast to all CPUs, but in that case, panic()/nmi_panic() are called after releasing nmi_reason_lock. So CPUs can't loop infinitely here. PATCH 4/4 allows us to broadcast external NMIs to all CPUs, and it causes infinite loop in raw_spin_lock(&nmi_reason_lock). So the above changes are needed. I'll move these chagnes to a later patch in the next version. Thanks, -- Hidehiro Kawai Hitachi, Ltd. Research & Development Group ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?