Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752732AbbHaJ5S (ORCPT ); Mon, 31 Aug 2015 05:57:18 -0400 Received: from mail7.hitachi.co.jp ([133.145.228.42]:37846 "EHLO mail7.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752221AbbHaJ5Q (ORCPT ); Mon, 31 Aug 2015 05:57:16 -0400 From: =?utf-8?B?5rKz5ZCI6Iux5a6PIC8gS0FXQUnvvIxISURFSElSTw==?= To: "'Peter Zijlstra'" CC: Jonathan Corbet , Ingo Molnar , "Eric W. Biederman" , "H. Peter Anvin" , Andrew Morton , Thomas Gleixner , Vivek Goyal , "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: [V3 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly Thread-Topic: [V3 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly Thread-Index: AQHQ0AtjXekgeO133USkzCimPcfuqJ4VA1yAgAJdTKCABPPXAIABVqwggAhInsD//24xgIAApHOg Date: Mon, 31 Aug 2015 09:57:11 +0000 Message-ID: <04EAB7311EE43145B2D3536183D1A84454958A58@GSjpTKYDCembx31.service.hitachi.net> References: <20150806054543.25766.29590.stgit@softrs> <20150806054543.25766.5914.stgit@softrs> <20150820230845.GF3161@worktop.event.rightround.com> <04EAB7311EE43145B2D3536183D1A8445493C868@GSjpTKYDCembx31.service.hitachi.net> <20150825145258.GS16853@twins.programming.kicks-ass.net> <04EAB7311EE43145B2D3536183D1A84454951595@GSjpTKYDCembx31.service.hitachi.net> <04EAB7311EE43145B2D3536183D1A8445495793E@GSjpTKYDCembx31.service.hitachi.net> <20150831090733.GI19282@twins.programming.kicks-ass.net> In-Reply-To: <20150831090733.GI19282@twins.programming.kicks-ass.net> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.198.220.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 t7V9vN9T014994 Content-Length: 1297 Lines: 40 > From: Peter Zijlstra [mailto:peterz@infradead.org] > On Mon, Aug 31, 2015 at 08:53:11AM +0000, 河合英宏 / KAWAI,HIDEHIRO wrote: > > > I understand your question. I don't intend to permit the recursive > > > call of crash_kexec() as for 'old_cpu != this_cpu' check. That is > > > needed for the case of panic() --> crash_kexec(). Since panic_cpu has > > > already been set to this_cpu in panic() (please see PATCH 1/4), no one > > > can run crash_kexec() without 'old_cpu != this_cpu' check. > > > > > > If you don't like this check, I would also be able to handle this case > > > like below: > > > > > > crash_kexec() > > > { > > > old_cpu = atomic_cmpxchg(&panic_cpu, -1, this_cpu); > > > if (old_cpu != -1) > > > return; > > > > > > __crash_kexec(); > > > } > > > > > > panic() > > > { > > > atomic_cmpxchg(&panic_cpu, -1, this_cpu); > > > __crash_kexec(); > > > ... > > > > > > > Is that OK? > > I suppose so, but I think me getting confused means comments can be > added/improved. OK, I'll improve comments and description 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?