Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752697AbbHaIxS (ORCPT ); Mon, 31 Aug 2015 04:53:18 -0400 Received: from mail7.hitachi.co.jp ([133.145.228.42]:48770 "EHLO mail7.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752339AbbHaIxQ (ORCPT ); Mon, 31 Aug 2015 04:53:16 -0400 From: =?utf-8?B?5rKz5ZCI6Iux5a6PIC8gS0FXQUnvvIxISURFSElSTw==?= To: =?utf-8?B?5rKz5ZCI6Iux5a6PIC8gS0FXQUnvvIxISURFSElSTw==?= , "'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: AQHQ0AtjXekgeO133USkzCimPcfuqJ4VA1yAgAJdTKCABPPXAIABVqwggAhInsA= Date: Mon, 31 Aug 2015 08:53:11 +0000 Message-ID: <04EAB7311EE43145B2D3536183D1A8445495793E@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> In-Reply-To: <04EAB7311EE43145B2D3536183D1A84454951595@GSjpTKYDCembx31.service.hitachi.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 t7V8rMhx014813 Content-Length: 2846 Lines: 86 Hello Peter, > From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of 河合英宏 / KAWAI, > > Hi, > > > From: Peter Zijlstra [mailto:peterz@infradead.org] > > > > On Sat, Aug 22, 2015 at 02:35:24AM +0000, 河合英宏 / KAWAI,HIDEHIRO wrote: > > > > From: Peter Zijlstra [mailto:peterz@infradead.org] > > > > > > > > On Thu, Aug 06, 2015 at 02:45:43PM +0900, Hidehiro Kawai wrote: > > > > > void crash_kexec(struct pt_regs *regs) > > > > > { > > > > > + int old_cpu, this_cpu; > > > > > + > > > > > + /* > > > > > + * `old_cpu == -1' means we are the first comer and crash_kexec() > > > > > + * was called without entering panic(). > > > > > + * `old_cpu == this_cpu' means crash_kexec() was called from panic(). > > > > > + */ > > > > > + this_cpu = raw_smp_processor_id(); > > > > > + old_cpu = atomic_cmpxchg(&panic_cpu, -1, this_cpu); > > > > > + if (old_cpu != -1 && old_cpu != this_cpu) > > > > > + return; > > > > > > > > This allows recursive calling of crash_kexec(), the Changelog did not > > > > mention that. Is this really required? > > > > > > What part are you arguing? Recursive call of crash_kexec() doesn't > > > happen. In the first place, one of the purpose of this patch is > > > to prevent a recursive call of crash_kexec() in the following case > > > as I stated in the description: > > > > > > CPU 0: > > > oops_end() > > > crash_kexec() > > > mutex_trylock() // acquired > > > > > > io_check_error() > > > panic() > > > crash_kexec() > > > mutex_trylock() // failed to acquire > > > infinite loop > > > > > > > Yes, but what to we want to do there? It seems to me that is wrong, we > > do not want to let a recursive crash_kexec() proceed. > > > > Whereas the condition you created explicitly allows this recursion by > > virtue of the 'old_cpu != this_cpu' check. > > 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? 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?