Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3309550imu; Sun, 11 Nov 2018 12:05:44 -0800 (PST) X-Google-Smtp-Source: AJdET5c8gaoz1jnqeKCzjk/vftiza3m+3iVTWSj4sHnNrIKj290rAUbX7R+XFLpQTHAmJcY9BI+F X-Received: by 2002:a62:c299:: with SMTP id w25-v6mr17973986pfk.205.1541966744570; Sun, 11 Nov 2018 12:05:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541966744; cv=none; d=google.com; s=arc-20160816; b=urgaA4YzdU5EePem/Nhf+Mg1seFERt1F+vEjfVNlhDrSOT+kbzAwGqhHKtJlx/XR+W thG4ts/esXOPvNochdU4EoGcNwyB3unm1P02UjgdN3msJhq8mmbGpxMT7i1htxQo3T0I e8yh4IW7C2yFUWO6Y4wi9fyJxAPJ9NC2SeW1h4+uM8yq1xtuxtaAwE29PumDpfELshQG ATzWnlthZ1qZb02J4QCV6y4I1FEKmEKQ4k8xpNkKXQI+kNKtXEqQ3tX3ZfCuDldl/qJh ja8m8TuaWC0oUMo91vOo7X1Ig60+qjUM59YQBMt3QOWxxzKE5/GV4tsVcC+/xp8tNaSs +F1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=FeV6yInI5IJ8eA8jlzQ5jbDW3Uf5+52ubPjyW3cX+no=; b=z7zrOkujLWKGwMO3JbI3qULYkZkDs84xr4OXIo0++hi8DePqOGRx5+qmEQRQ/o9USE LEPvNYvn5/xhT5KnnLbmK9/iFSAr7N4h1SjRPLZQ6mvsLYCsqcbCDX/NT8Wrq2UNu6PW rkqycG5S7YcVqZ5vwKHpc5Ag4gTfM9rJbLhnHa5syuwX26JgW8K/qEicB0JpQhMrJFn+ y0C/bkX2pMNdjNtuXhV3l1SbFWNJNP5cR3g4ggAqwLa2Sgn5UNajTBFr5LnR+M6f4mBC 530qqqpJqkDinMVu+qoW+dmNq4WGrTJ4ZfX4/Ev3CBszPFNLUkbajYoJmhWjYvVzUnP/ U8cA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l137-v6si18541460pfd.260.2018.11.11.12.05.29; Sun, 11 Nov 2018 12:05:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731143AbeKLFyL (ORCPT + 99 others); Mon, 12 Nov 2018 00:54:11 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:51708 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726508AbeKLFyJ (ORCPT ); Mon, 12 Nov 2018 00:54:09 -0500 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gLvtD-0000l4-Ky; Sun, 11 Nov 2018 19:59:23 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gLvsO-0001Og-Bk; Sun, 11 Nov 2018 19:58:32 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Michael Ellerman" , "Mahesh Salgaonkar" Date: Sun, 11 Nov 2018 19:49:05 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 033/366] powerpc/fadump: Unregister fadump on kexec down path. In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.61-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Mahesh Salgaonkar commit 722cde76d68e8cc4f3de42e71c82fd40dea4f7b9 upstream. Unregister fadump on kexec down path otherwise the fadump registration in new kexec-ed kernel complains that fadump is already registered. This makes new kernel to continue using fadump registered by previous kernel which may lead to invalid vmcore generation. Hence this patch fixes this issue by un-registering fadump in fadump_cleanup() which is called during kexec path so that new kernel can register fadump with new valid values. Fixes: b500afff11f6 ("fadump: Invalidate registration and release reserved memory for general use.") Signed-off-by: Mahesh Salgaonkar Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings --- arch/powerpc/kernel/fadump.c | 3 +++ 1 file changed, 3 insertions(+) --- a/arch/powerpc/kernel/fadump.c +++ b/arch/powerpc/kernel/fadump.c @@ -1025,6 +1025,9 @@ void fadump_cleanup(void) init_fadump_mem_struct(&fdm, fdm_active->cpu_state_data.destination_address); fadump_invalidate_dump(&fdm); + } else if (fw_dump.dump_registered) { + /* Un-register Firmware-assisted dump if it was registered. */ + fadump_unregister_dump(&fdm); } }