From patchwork Tue Mar 22 21:46:17 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12789237 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76D62C433FE for ; Tue, 22 Mar 2022 21:46:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0CA9B6B0156; Tue, 22 Mar 2022 17:46:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 079DC6B0157; Tue, 22 Mar 2022 17:46:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D725C6B0158; Tue, 22 Mar 2022 17:46:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id C6C7D6B0156 for ; Tue, 22 Mar 2022 17:46:19 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id A9A0481A3D for ; Tue, 22 Mar 2022 21:46:19 +0000 (UTC) X-FDA: 79273356078.10.408EB16 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf04.hostedemail.com (Postfix) with ESMTP id 4164C40021 for ; Tue, 22 Mar 2022 21:46:19 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AB1CC6165D; Tue, 22 Mar 2022 21:46:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0DC70C340EC; Tue, 22 Mar 2022 21:46:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1647985578; bh=rVcXrpMApCnqbgK4FnFZ6aZ0OghhdBHDhXCnJqs3fYI=; h=Date:To:From:In-Reply-To:Subject:From; b=mM9yP7B55z3rV7AECvjzPz28YcUlLU/2X/Vz+4F+KqAeAE41tEsyvKR1YVlDPAFTw Cj1j1hNqOqbHCrMkCKI5CjhUO8FluGDwe2dQDyFAw7a8IYP1gKfa6ilD/zS2BMMnlh LWjIwyNxlQdmA3puTLc6Dknwnvj9YeR4k/TSqw8E= Date: Tue, 22 Mar 2022 14:46:17 -0700 To: sourabhjain@linux.ibm.com,osalvador@suse.de,mpe@ellerman.id.au,mike.kravetz@oracle.com,mahesh@linux.ibm.com,david@redhat.com,hbathini@linux.ibm.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220322143803.04a5e59a07e48284f196a2f9@linux-foundation.org> Subject: [patch 153/227] powerpc/fadump: opt out from freeing pages on cma activation failure Message-Id: <20220322214618.0DC70C340EC@smtp.kernel.org> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 4164C40021 X-Stat-Signature: f3afg7c64kk83hc3uuuo7e31ah5ozj75 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=mM9yP7B5; dmarc=none; spf=pass (imf04.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Rspam-User: X-HE-Tag: 1647985579-74845 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Hari Bathini Subject: powerpc/fadump: opt out from freeing pages on cma activation failure With commit a4e92ce8e4c8 ("powerpc/fadump: Reservationless firmware assisted dump"), Linux kernel's Contiguous Memory Allocator (CMA) based reservation was introduced in fadump. That change was aimed at using CMA to let applications utilize the memory reserved for fadump while blocking it from being used for kernel pages. The assumption was, even if CMA activation fails for whatever reason, the memory still remains reserved to avoid it from being used for kernel pages. But commit 072355c1cf2d ("mm/cma: expose all pages to the buddy if activation of an area fails") breaks this assumption as it started exposing all pages to buddy allocator on CMA activation failure. It led to warning messages like below while running crash-utility on vmcore of a kernel having above two commits: crash: seek error: kernel virtual address: To fix this problem, opt out from exposing pages to buddy allocator on CMA activation failure for fadump reserved memory. Link: https://lkml.kernel.org/r/20220117075246.36072-3-hbathini@linux.ibm.com Signed-off-by: Hari Bathini Acked-by: David Hildenbrand Acked-by: Michael Ellerman Cc: Mahesh Salgaonkar Cc: Mike Kravetz Cc: Oscar Salvador Cc: Sourabh Jain Signed-off-by: Andrew Morton --- arch/powerpc/kernel/fadump.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/arch/powerpc/kernel/fadump.c~powerpc-fadump-opt-out-from-freeing-pages-on-cma-activation-failure +++ a/arch/powerpc/kernel/fadump.c @@ -113,6 +113,12 @@ static int __init fadump_cma_init(void) } /* + * If CMA activation fails, keep the pages reserved, instead of + * exposing them to buddy allocator. Same as 'fadump=nocma' case. + */ + cma_reserve_pages_on_error(fadump_cma); + + /* * So we now have successfully initialized cma area for fadump. */ pr_info("Initialized 0x%lx bytes cma area at %ldMB from 0x%lx "