Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2271293iof; Wed, 8 Jun 2022 01:02:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwF45yjz0O5yfBV0Kr0NyY+JUjN9ucbJEhGQuCUcg/y+1l0Wa8Feuo0PxuS2FCnVmE63wyH X-Received: by 2002:a05:6a00:e8e:b0:518:287c:ce82 with SMTP id bo14-20020a056a000e8e00b00518287cce82mr33056260pfb.4.1654675376458; Wed, 08 Jun 2022 01:02:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654675376; cv=none; d=google.com; s=arc-20160816; b=tyJmxz9TXPmpj3FtAAnVloaFHOKyRrp19bNgxP8T2hoyouXhf+F2BcU2B9ElY6jnpN r58j9hSRna6zgrwjgbbKOQEQ2dcKDZW//2/FDX8ZNi4lb4c+WvP12zRZ69UAyBaCCC2u 3paOxv7Z3eI8lSm/wObi6KnPWk5I7e54hBdEc+sFY1fs08dw9Ue5L1tea9rx8280YP1X yRozk/EfQgiJLsZVOBHBzAQtG9jHe07+heQgPtJyoG5pIuNjJ/SCmli0a1M6CV8yVb5u R4VhemHZfpudxIogc+5GaHTYxgKP/fNxyxVNjVTNJjCD3BQ0GvhCX/cc1XKNaqFdVXuQ eDMA== 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=CdV29cDYM7JFTwvOM1eI7YqfJ48BAVqqyxEAcQN7Ghw=; b=fC29MBvw4T7QR1CrHuQ6SXhOeA7fF9ERvxe8dbVmeVAsTmoudpy52cUOTMD6yKmrkd JUzXESojPRB6J8JDwUKOFjMTNJNXY9w2Rb1PTxGH5FB7K+R/Rz3kbi4xPdNIkjzpCP83 3IZ/DWsDDy4BVCVidEixJGiOC1c0u2wFGEPycyPl12s/12Wa1+at/NGDvroZrCW/rcBq uNgMyjWmeD5r5mfUWqsUHEJOj/6mSdjd6a9Z+P0laPR4pWvY4oxOs4EI7kjWYzlybWfJ EzqdlpzKfnmgb1TM0G307Fqs2NKQ6bpu4t7kzKN4MzMxjudSu8gfLZxm4UXaSLI4JppR RKlA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=kFew4n6n; 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 l8-20020a63ba48000000b003fc19a5f892si27614389pgu.55.2022.06.08.01.02.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jun 2022 01:02:56 -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=kFew4n6n; 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 7D30521F99A; Wed, 8 Jun 2022 00:32:16 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355970AbiFGTbF (ORCPT + 99 others); Tue, 7 Jun 2022 15:31:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352558AbiFGSiw (ORCPT ); Tue, 7 Jun 2022 14:38:52 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9E34E1842F4; Tue, 7 Jun 2022 10:58:25 -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 dfw.source.kernel.org (Postfix) with ESMTPS id D1F6E618DB; Tue, 7 Jun 2022 17:58:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E40FEC36B03; Tue, 7 Jun 2022 17:58:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654624695; bh=p0aLmWRISE6ht0b6iIng3ogD2g7pyk9Y428MhTNJoag=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kFew4n6nBdhRO2qYHWzrvIYafDqdEOqRMb5apNrQSa2iTzzu6M8dCyVxzGPAfD5PD X7f0sEbEs3yimXrRx3x3lKQx151MgLjjFUB4S3flOMSrPFm8s66DiN0U0ugoUkxmky VPM+P/U9iRIth4hup8GE2MD0SUnJzO7FCp0Pwokg= 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.15 420/667] powerpc/fadump: fix PT_LOAD segment for boot memory area Date: Tue, 7 Jun 2022 19:01:25 +0200 Message-Id: <20220607164947.332423795@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220607164934.766888869@linuxfoundation.org> References: <20220607164934.766888869@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 60f5fc14aa23..ad1c4575c61c 100644 --- a/arch/powerpc/kernel/fadump.c +++ b/arch/powerpc/kernel/fadump.c @@ -861,7 +861,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) { @@ -880,7 +879,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