From mboxrd@z Thu Jan 1 00:00:00 1970 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 > @@ -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ʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail4.hitachi.co.jp ([133.145.228.5]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1a4JYs-0007Yo-V4 for kexec@lists.infradead.org; Thu, 03 Dec 2015 02:23:59 +0000 From: =?utf-8?B?5rKz5ZCI6Iux5a6PIC8gS0FXQUnvvIxISURFSElSTw==?= Subject: RE: [V5 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context 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> Content-Language: ja-JP MIME-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org 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" , 'Steven Rostedt' , Michal Hocko , Ingo Molnar , Borislav Petkov , =?utf-8?B?5bmz5p2+6ZuF5bezIC8gSElSQU1BVFXvvIxNQVNBTUk=?= > @@ -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 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec