Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757992AbbLBL5p (ORCPT ); Wed, 2 Dec 2015 06:57:45 -0500 Received: from mail7.hitachi.co.jp ([133.145.228.42]:39679 "EHLO mail7.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756697AbbLBL5n (ORCPT ); Wed, 2 Dec 2015 06:57:43 -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+AgAuxnQA= Date: Wed, 2 Dec 2015 11:57:38 +0000 Message-ID: <04EAB7311EE43145B2D3536183D1A84454A3B032@GSjpTKYDCembx31.service.hitachi.net> References: <20151120093641.4285.97253.stgit@softrs> <20151120093648.4285.17715.stgit@softrs> <20151125095457.GB29499@pd.tnic> In-Reply-To: <20151125095457.GB29499@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.41] 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 tB2BvoCL003567 Content-Length: 1570 Lines: 48 Hello Borislav, Sorry, I haven't replied to this mail yet. > On Fri, Nov 20, 2015 at 06:36:48PM +0900, Hidehiro Kawai wrote: ... > > +void crash_kexec(struct pt_regs *regs) > > +{ > > + int old_cpu, this_cpu; > > + > > + /* > > + * Only one CPU is allowed to execute the crash_kexec() code as with > > + * panic(). Otherwise parallel calls of panic() and crash_kexec() > > + * may stop each other. To exclude them, we use panic_cpu here too. > > + */ > > + this_cpu = raw_smp_processor_id(); > > + old_cpu = atomic_cmpxchg(&panic_cpu, -1, this_cpu); > > + if (old_cpu == -1) { > > + /* This is the 1st CPU which comes here, so go ahead. */ > > + __crash_kexec(regs); > > + > > + /* > > + * Reset panic_cpu to allow another panic()/crash_kexec() > > + * call. > > So can we make __crash_kexec() return error values? > > * failed to grab kexec_mutex -> reset panic_cpu > > * no kexec_crash_image -> no need to reset it, all future crash_kexec() > calls won't work so no need to run into that path anymore. However, this could > be problematic if we want the other CPUs to panic. Do we care? > > * machine_kexec successful -> doesn't matter We can do so, but I think resetting panic_cpu always would be simpler and safer. Although checking kexec_crash_image each time is pointless, it doesn't cause any actual problem. 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?