Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2204593iof; Tue, 7 Jun 2022 23:08:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwDDRDHhPd5vdiq9XDPcPCfjH54o5tT/7MYb2dEMzKNGDAnV1lk9tdRPoY6iXe6qzSqu3NI X-Received: by 2002:a17:902:8c91:b0:167:895f:9684 with SMTP id t17-20020a1709028c9100b00167895f9684mr10745569plo.133.1654668513416; Tue, 07 Jun 2022 23:08:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654668513; cv=none; d=google.com; s=arc-20160816; b=pybQrIPqFE4n3TaWVaH/Qnzos0hmIuWpzeE4u1ZuFWI557/e6l5n3VRLiFnREeyoT8 VUHWxZijAt0H2FYaoJuSXPpf5YSHNy8ObOMOxZkV/MCnznOGJWVC5jOXRoS0noGTyd6/ abXnldM4oTEZ6WuxwNU+lekJV7OAemotOAi6eJEpjEX1RMxAx15FmC5CO9iLciDDmwsR QWIH/5S1pOHPmgA6TSwTQemoy0ahCL/DqjTZeoqT+6p41eVyAPVGEuRslVZMisrjslqQ Hw2peWsqTu68Bj0oj7MZnbFF4oJiY/bqX7J7fTwyPYmbt+HvhCQe4VbqB2PUzFBBpagS KUIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=Dt+yCpAJKHLQuIgqb/sK9x13SdtxLPcpBb9xLc+uMIk=; b=CKLyXQwaq3tPQRMasZjLQvF+edynOL0wcGoP5AQsxd1moPyr2MFFUSfhLxeQtWshsg MjPd7vvoaqQprno/yjCyDF1Blz5Z8eYLZquXPgTxiuLnrvnpzvW77sJnJXOkVOropqjW ilLq8zTbx+NCUhPJeEZBbtghFrIyPxGtKK+jmLxa5xNiyQ14jj0H2eP/WTdowRArOpzL eg3TdXq2LVadl3QcOGCuYEYNEr4zo+Pk9M2EngUWWCXp6VKFTB1GbAYqwOZ3pIj0Y1A2 LTtmjWBHP++gBmfuzFhfcwxCk0Wyg1pBDBYc26LzdVxrrjrJGjjy1DfrwK86JxkvmjWl Q/zg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=oUQwiIvf; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id iw19-20020a170903045300b0016252715440si25806029plb.494.2022.06.07.23.08.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 23:08:33 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=oUQwiIvf; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id DFA83DECD0; Tue, 7 Jun 2022 22:31:31 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1382057AbiFHBfv (ORCPT + 99 others); Tue, 7 Jun 2022 21:35:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1384099AbiFGVyI (ORCPT ); Tue, 7 Jun 2022 17:54:08 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 76BCFBC6D7; Tue, 7 Jun 2022 12:13:01 -0700 (PDT) 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 ams.source.kernel.org (Postfix) with ESMTPS id B9F9CB823AE; Tue, 7 Jun 2022 19:12:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 29FB1C385A2; Tue, 7 Jun 2022 19:12:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654629144; bh=ChG5KglVMpbMmET+uPYKCKvlwS3FJg7jw68kdmf/5z0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oUQwiIvf+QJGgoFGdF79fhWnDqUBAwJawB3SQBidzo/r+wPjgl0tKm0V90l9CMtCw NJVOZfvMjucUUG7vcMLvH8DekGn0ek5ZBnymVs3uFk5CvVqqXmbaAxtugJ0cUSGZqs vpa5ebmTypXJdEbfdU1ov5Y4EuQw44WQA/nQ/Dk0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hari Bathini , Michael Ellerman , Sasha Levin Subject: [PATCH 5.18 583/879] powerpc/fadump: fix PT_LOAD segment for boot memory area Date: Tue, 7 Jun 2022 19:01:41 +0200 Message-Id: <20220607165019.775638526@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220607165002.659942637@linuxfoundation.org> References: <20220607165002.659942637@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Hari Bathini [ Upstream commit 15eb77f873255cf9f4d703b63cfbd23c46579654 ] Boot memory area is setup as separate PT_LOAD segment in the vmcore as it is moved by f/w, on crash, to a destination address provided by the kernel. Having separate PT_LOAD segment helps in handling the different physical address and offset for boot memory area in the vmcore. Commit ced1bf52f477 ("powerpc/fadump: merge adjacent memory ranges to reduce PT_LOAD segements") inadvertly broke this pre-condition for cases where some of the first kernel memory is available adjacent to boot memory area. This scenario is rare but possible when memory for fadump could not be reserved adjacent to boot memory area owing to memory hole or such. Reading memory from a vmcore exported in such scenario provides incorrect data. Fix it by ensuring no other region is folded into boot memory area. Fixes: ced1bf52f477 ("powerpc/fadump: merge adjacent memory ranges to reduce PT_LOAD segements") Signed-off-by: Hari Bathini Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220406093839.206608-2-hbathini@linux.ibm.com Signed-off-by: Sasha Levin --- arch/powerpc/kernel/fadump.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c index 65562c4a0a69..dc2350b288cf 100644 --- a/arch/powerpc/kernel/fadump.c +++ b/arch/powerpc/kernel/fadump.c @@ -867,7 +867,6 @@ static int fadump_alloc_mem_ranges(struct fadump_mrange_info *mrange_info) sizeof(struct fadump_memory_range)); return 0; } - static inline int fadump_add_mem_range(struct fadump_mrange_info *mrange_info, u64 base, u64 end) { @@ -886,7 +885,12 @@ static inline int fadump_add_mem_range(struct fadump_mrange_info *mrange_info, start = mem_ranges[mrange_info->mem_range_cnt - 1].base; size = mem_ranges[mrange_info->mem_range_cnt - 1].size; - if ((start + size) == base) + /* + * Boot memory area needs separate PT_LOAD segment(s) as it + * is moved to a different location at the time of crash. + * So, fold only if the region is not boot memory area. + */ + if ((start + size) == base && start >= fw_dump.boot_mem_top) is_adjacent = true; } if (!is_adjacent) { -- 2.35.1