From mboxrd@z Thu Jan 1 00:00:00 1970 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5D05C7EE23 for ; Tue, 30 May 2023 22:04:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231171AbjE3WEj (ORCPT ); Tue, 30 May 2023 18:04:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39130 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233637AbjE3WEh (ORCPT ); Tue, 30 May 2023 18:04:37 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CF6F110D for ; Tue, 30 May 2023 15:04:34 -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 582DE6283A for ; Tue, 30 May 2023 22:04:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AEEF2C433EF; Tue, 30 May 2023 22:04:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1685484273; bh=xG+pEoVOO73wcM/2JlM3XPUrDdk/2zzeyAEoBLUUDCg=; h=Date:To:From:Subject:From; b=isIgpNxQxq56/mzG4z+umvCh54iXEV+kszZn5qtGPyu6s9Dbk1ig5qMNNHPeStDFr G+4MtQwOrZEP87V0g2qKP87JzP0pgbOckrO8aX/LAetLxCbkRuBocvveStQyT4RBHe KGsXdFfOV1ah5UqST4/eUe/+BtbKIJ6XLbYh6edg= Date: Tue, 30 May 2023 15:04:33 -0700 To: mm-commits@vger.kernel.org, holzheu@linux.vnet.ibm.com, ebiederm@xmission.com, bhe@redhat.com, amwang@redhat.com, thunder.leizhen@huawei.com, akpm@linux-foundation.org From: Andrew Morton Subject: + kexec-fix-a-memory-leak-in-crash_shrink_memory.patch added to mm-nonmm-unstable branch Message-Id: <20230530220433.AEEF2C433EF@smtp.kernel.org> Precedence: bulk Reply-To: linux-kernel@vger.kernel.org List-ID: X-Mailing-List: mm-commits@vger.kernel.org The patch titled Subject: kexec: fix a memory leak in crash_shrink_memory() has been added to the -mm mm-nonmm-unstable branch. Its filename is kexec-fix-a-memory-leak-in-crash_shrink_memory.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/kexec-fix-a-memory-leak-in-crash_shrink_memory.patch This patch will later appear in the mm-nonmm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Zhen Lei Subject: kexec: fix a memory leak in crash_shrink_memory() Date: Sat, 27 May 2023 20:34:34 +0800 Patch series "kexec: enable kexec_crash_size to support two crash kernel regions". When crashkernel=X fails to reserve region under 4G, it will fall back to reserve region above 4G and a region of the default size will also be reserved under 4G. Unfortunately, /sys/kernel/kexec_crash_size only supports one crash kernel region now, the user cannot sense the low memory reserved by reading /sys/kernel/kexec_crash_size. Also, low memory cannot be freed by writing this file. For example: resource_size(crashk_res) = 512M resource_size(crashk_low_res) = 256M The result of 'cat /sys/kernel/kexec_crash_size' is 512M, but it should be 768M. When we execute 'echo 0 > /sys/kernel/kexec_crash_size', the size of crashk_res becomes 0 and resource_size(crashk_low_res) is still 256 MB, which is incorrect. Since crashk_res manages the memory with high address and crashk_low_res manages the memory with low address, crashk_low_res is shrunken only when all crashk_res is shrunken. And because when there is only one crash kernel region, crashk_res is always used. Therefore, if all crashk_res is shrunken and crashk_low_res still exists, swap them. This patch (of 6): If the value of parameter 'new_size' is in the semi-open and semi-closed interval (crashk_res.end - KEXEC_CRASH_MEM_ALIGN + 1, crashk_res.end], the calculation result of ram_res is: ram_res->start = crashk_res.end + 1 ram_res->end = crashk_res.end The operation of insert_resource() fails, and ram_res is not added to iomem_resource. As a result, the memory of the control block ram_res is leaked. In fact, on all architectures, the start address and size of crashk_res are already aligned by KEXEC_CRASH_MEM_ALIGN. Therefore, we do not need to round up crashk_res.start again. Instead, we should round up 'new_size' in advance. Link: https://lkml.kernel.org/r/20230527123439.772-1-thunder.leizhen@huawei.com Link: https://lkml.kernel.org/r/20230527123439.772-2-thunder.leizhen@huawei.com Fixes: 6480e5a09237 ("kdump: add missing RAM resource in crash_shrink_memory()") Fixes: 06a7f711246b ("kexec: premit reduction of the reserved memory size") Signed-off-by: Zhen Lei Cc: Baoquan He Cc: Cong Wang Cc: Eric W. Biederman Cc: Michael Holzheu Signed-off-by: Andrew Morton --- kernel/kexec_core.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- a/kernel/kexec_core.c~kexec-fix-a-memory-leak-in-crash_shrink_memory +++ a/kernel/kexec_core.c @@ -1122,6 +1122,7 @@ int crash_shrink_memory(unsigned long ne start = crashk_res.start; end = crashk_res.end; old_size = (end == 0) ? 0 : end - start + 1; + new_size = roundup(new_size, KEXEC_CRASH_MEM_ALIGN); if (new_size >= old_size) { ret = (new_size == old_size) ? 0 : -EINVAL; goto unlock; @@ -1133,9 +1134,7 @@ int crash_shrink_memory(unsigned long ne goto unlock; } - start = roundup(start, KEXEC_CRASH_MEM_ALIGN); - end = roundup(start + new_size, KEXEC_CRASH_MEM_ALIGN); - + end = start + new_size; crash_free_reserved_phys_range(end, crashk_res.end); if ((start == end) && (crashk_res.parent != NULL)) _ Patches currently in -mm which might be from thunder.leizhen@huawei.com are kexec-fix-a-memory-leak-in-crash_shrink_memory.patch kexec-delete-a-useless-check-in-crash_shrink_memory.patch kexec-clear-crashk_res-if-all-its-memory-has-been-released.patch kexec-improve-the-readability-of-crash_shrink_memory.patch kexec-add-helper-__crash_shrink_memory.patch kexec-enable-kexec_crash_size-to-support-two-crash-kernel-regions.patch