Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753776AbbG0OzM (ORCPT ); Mon, 27 Jul 2015 10:55:12 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:36931 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752621AbbG0OzK (ORCPT ); Mon, 27 Jul 2015 10:55:10 -0400 Date: Mon, 27 Jul 2015 16:55:06 +0200 From: Michal Hocko To: Hidehiro Kawai Cc: Jonathan Corbet , Peter Zijlstra , 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, Masami Hiramatsu Subject: Re: [V2 PATCH 2/3] kexec: Fix race between panic() and crash_kexec() called directly Message-ID: <20150727145506.GG11317@dhcp22.suse.cz> References: <20150727015850.4928.87717.stgit@softrs> <20150727015850.4928.15194.stgit@softrs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150727015850.4928.15194.stgit@softrs> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1574 Lines: 45 On Mon 27-07-15 10:58:50, Hidehiro Kawai wrote: [...] > @@ -1472,6 +1472,18 @@ void __weak crash_unmap_reserved_pages(void) > > 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(&panicking_cpu, -1, this_cpu); > + if (old_cpu != -1 && old_cpu != this_cpu) > + return; > + > /* Take the kexec_mutex here to prevent sys_kexec_load > * running on one cpu from replacing the crash kernel > * we are using after a panic on a different cpu. > @@ -1491,6 +1503,14 @@ void crash_kexec(struct pt_regs *regs) > } > mutex_unlock(&kexec_mutex); > } > + > + /* > + * If we came here from panic(), we have to keep panicking_cpu > + * to prevent other cpus from entering panic(). Otherwise, > + * resetting it so that other cpus can enter panic()/crash_kexec(). > + */ > + if (old_cpu == this_cpu) > + atomic_set(&panicking_cpu, -1); This do the opposite what the comment says, wouldn't it? You should check old_cpu == -1. Also atomic_set doesn't imply memory barriers which might be a problem. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/