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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A5170CD6E56 for ; Mon, 1 Jun 2026 09:49:39 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4gTTgj6wCKz2yth; Mon, 01 Jun 2026 19:49:05 +1000 (AEST) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip=113.46.200.221 ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1780307345; cv=none; b=M2kT7QzgiswiqW1M9EhoWsBcM7FmVRKagVxPB4C/ybQS66J5TK6kJV1sXkcp2YhByzMl515JtaLyoBscmljlrMweYHNBA3m+/+a3zX2VTV8+ez3xYgS2T9ZyvFU4St+uvOBnwQB/AgvSBRaycQ9ZNo2hIC9R3vYl3k8sBzUi2GmEeStZgm9ZBXgfIfh9noNLlvdMXIktmdSKlOjawsbU3Af0iPTfE+r76Brv2o13C8w8RzF/5lSJuzpjBeCO9ZPz/uhHlyT7+45moSYEXtkBv6HpyaDC5JrqGyeeHa640m6PLeuOpvR2N/Bq6WL/j0iRVGaiIU24zOXbE975SAeNXg== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1780307345; c=relaxed/relaxed; bh=3CM+Au3SXosW29XrHZBLTzStvKPXPYXLJ81pyBZwyQo=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Pn0yT81ZWssGdWihWMqqB5MTBm0jlS39eXl78T5qWjgX3tqBiLSasmjZ7VPZmHzvoDH2U2sWRG89DyUVJT4jL8ZLkTwyWonFAsnKzwG8FZbpkNqoSGUIJlohspKZQ13yGt1f3INSRXeecfrk4jASnQF6vN2x4VdR/UkDConxLqdsy3wCOoxOD5LOGhR/pnHFjs90cevxUg5BthmEfwZKuy8bUDbuo++mXy0j4MddChCpCsB3tcgQmyzdzJx0Z1WeEhqrnJsw8LOikxxS2GEVDp15OpB/qIPjJzjgwrjJsE+fMDFukeo59W0he3f3JWsDWSOSAQI60sL0yjkjgjZz/A== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; dkim=pass (1024-bit key; unprotected) header.d=huawei.com header.i=@huawei.com header.a=rsa-sha256 header.s=dkim header.b=K+9Cpzom; dkim-atps=neutral; spf=pass (client-ip=113.46.200.221; helo=canpmsgout06.his.huawei.com; envelope-from=ruanjinjie@huawei.com; receiver=lists.ozlabs.org) smtp.mailfrom=huawei.com Authentication-Results: lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=huawei.com header.i=@huawei.com header.a=rsa-sha256 header.s=dkim header.b=K+9Cpzom; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=huawei.com (client-ip=113.46.200.221; helo=canpmsgout06.his.huawei.com; envelope-from=ruanjinjie@huawei.com; receiver=lists.ozlabs.org) Received: from canpmsgout06.his.huawei.com (canpmsgout06.his.huawei.com [113.46.200.221]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4gTTgj0WMlz2ytJ for ; Mon, 01 Jun 2026 19:49:04 +1000 (AEST) dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=3CM+Au3SXosW29XrHZBLTzStvKPXPYXLJ81pyBZwyQo=; b=K+9Cpzombw+R1hz+4oTY8H0FgupdRElbxcNkGJexiHXFS/yuEYiEV0xUzMPD0jBtDpTNTrOUd 5pjSAy+NXj9LNHESyhBYSfroq164Dq/6YwKWnvf9H9/9K0QFK3HcM9jHW3afdFVuVnBCUGVg5Sa pJKFnhLybZVSXQuwmunxwx0= Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout06.his.huawei.com (SkyGuard) with ESMTPS id 4gTTVd1hx6zRhQr; Mon, 1 Jun 2026 17:41:13 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 98392201E9; Mon, 1 Jun 2026 17:49:01 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:48:57 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 07/23] arm64: kexec_file: Fix CMA page leaks during segment placement retry loops Date: Mon, 1 Jun 2026 17:47:49 +0800 Message-ID: <20260601094805.2928614-8-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> X-Mailing-List: linuxppc-dev@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Archive: , List-Subscribe: , , List-Unsubscribe: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Sashiko AI code review pointed out, during arm64 kexec image placement retry loops in image_load(), the loader repeatedly attempts to find a suitable memory hole for the kernel and its associated segments (initrd, dtb, etc.). When a placement attempt fails midway, the core framework rolls back `image->nr_segments` to its initial state to purge the failed segments logically. However, this truncation causes a severe background memory leak. Any CMA pages successfully allocated via kexec_add_buffer() during the failed attempt are recorded in the `image->segment_cma` array. Since the subsequent global kimage_free_cma() cleanup only iterates up to the truncated (smaller) `nr_segments` boundary, these allocated CMA pages outside the new boundary become completely orphaned and permanently leaked. Fix this by leverage the newly introduced generic kexec_free_segment_cma() helper to execute fine-grained memory reclamation before any truncation occurs: 1. In image_load(), explicitly invoke kexec_free_segment_cma() to release the CMA buffer allocated for the current failed kernel segment before decrementing `image->nr_segments`. 2. In the error path of load_other_segments(), iterate backward from the failed segment index down to `orig_segments`, sequentially freeing each orphan CMA segment allocation before restoring the initial segment count. This guarantees that all temporary CMA pages allocated during placement failures are cleanly returned to the contiguous memory allocator, eliminating silent background memory leaks across all retry paths. Cc: Catalin Marinas Cc: Will Deacon Cc: Breno Leitao Cc: Pratyush Yadav Cc: Andrew Morton Cc: Yeoreum Yun Cc: Kees Cook Cc: "Rob Herring (Arm)" Cc: Baoquan He Cc: Coiby Xu Cc: Alexander Graf Cc: Pasha Tatashin Cc: stable@vger.kernel.org Fixes: 07d24902977e4 ("kexec: enable CMA based contiguous allocation") Signed-off-by: Jinjie Ruan --- arch/arm64/kernel/kexec_image.c | 1 + arch/arm64/kernel/machine_kexec_file.c | 5 ++++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c index b70f4df15a1a..ffcb7f9075e6 100644 --- a/arch/arm64/kernel/kexec_image.c +++ b/arch/arm64/kernel/kexec_image.c @@ -107,6 +107,7 @@ static void *image_load(struct kimage *image, * We couldn't find space for the other segments; erase the * kernel segment and try the next available hole. */ + kexec_free_segment_cma(image, kernel_segment_number); image->nr_segments -= 1; kbuf.buf_min = kernel_segment->mem + kernel_segment->memsz; kbuf.mem = KEXEC_BUF_MEM_UNKNOWN; diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c index e31fabed378a..13c247c28866 100644 --- a/arch/arm64/kernel/machine_kexec_file.c +++ b/arch/arm64/kernel/machine_kexec_file.c @@ -195,7 +195,10 @@ int load_other_segments(struct kimage *image, return 0; out_err: - image->nr_segments = orig_segments; + while (image->nr_segments > orig_segments) { + kexec_free_segment_cma(image, image->nr_segments - 1); + image->nr_segments--; + } kvfree(dtb); return ret; } -- 2.34.1