Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758060AbbLCCBq (ORCPT ); Wed, 2 Dec 2015 21:01:46 -0500 Received: from mail7.hitachi.co.jp ([133.145.228.42]:44291 "EHLO mail7.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757500AbbLCCBo (ORCPT ); Wed, 2 Dec 2015 21:01:44 -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 , =?utf-8?B?5bmz5p2+6ZuF5bezIC8gSElSQU1BVFXvvIxNQVNBTUk=?= Subject: RE: [V5 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly Thread-Topic: [V5 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly Thread-Index: AQHRI3eQ3182xzsAkE+t80SD59JIOJ6r8N+AgAuxnQD//684gIABPFXA Date: Thu, 3 Dec 2015 02:01:38 +0000 Message-ID: <04EAB7311EE43145B2D3536183D1A84454A3CD95@GSjpTKYDCembx31.service.hitachi.net> References: <20151120093641.4285.97253.stgit@softrs> <20151120093648.4285.17715.stgit@softrs> <20151125095457.GB29499@pd.tnic> <04EAB7311EE43145B2D3536183D1A84454A3B032@GSjpTKYDCembx31.service.hitachi.net> <20151202154023.GH3783@pd.tnic> In-Reply-To: <20151202154023.GH3783@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.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 tB321pvB010914 Content-Length: 1563 Lines: 54 > On Wed, Dec 02, 2015 at 11:57:38AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote: > > We can do so, but I think resetting panic_cpu always would be > > simpler and safer. I'll state in detail. When we call crash_kexec() without entering panic() and return from it, panic() should be called eventually. But the code paths are a bit complicated and there are many implementations for each architecture. So one day, this assumption may be broken; the CPU doesn't call panic(). Or the CPU may fail to call panic() because we are already in insane state. It would be nervous, but allowing another CPU to process panic routines by resetting panic_cpu is safer approach. > Well, I think executing code needlessly *especially* at panic time is > not all that rosy either. > > Besides something like this: > > static bool kexec_failed; > > ... > > if (crash_kexec_post_notifiers && !kexec_failed) > kexec_failed = __crash_kexec(NULL); > > is as simple as it gets. Since this code is executed only once due to panic_cpu, I think introducing this logic is not much valuable. Also, current implementation is already quite simple: panic() { ... __crash_kexec(NULL) { if (mutex_trylock(&kexec_mutex)) { if (kexec_crash_image) { /* don't return */ } } mutex_unlock(&kexec_mutex) } How do you think? Regards, -- Hidehiro Kawai Hitachi, Ltd. Research & Development Group ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?