From nobody Mon Dec 1 22:07:24 2025 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4C5A727AC3A for ; Sun, 30 Nov 2025 12:00:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764504013; cv=none; b=drGIIcuU0mgYtaxS/0J0tXazSEpkqWLfClJXcCTXhdXX6VogD9t+T7X/kJi5lDuiurlJecjGcg2rpDSlrvw3ciuYjYeLPgQYWMdz1jXbVRvuGb7yHn0mqGaqA4ANoR/zr2EpZx07kpN89QmouHvmbXceuN4SFm2W4R6t95RltTk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764504013; c=relaxed/simple; bh=jv+4rsi+Hmnx5cpl+oErfHlMzRbCj0okDAEUKEr+vg0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=UKh43t/gynAkProA54i+CtvUXKJejf+F9s8Tan0HqrZ2N2bKxU/XgeYFRah+WUBwz37KncpVjyJSnW+NrpJXPmazTzE6DsJ+B0Uz5RMlk9Rvd2EObrAkjyKXr+Iic/Ww8CXY9ByAKBzhJ1kG73VqW4dgBU9c0Tk/JLM/4h52f6s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=flnj9Hdu; arc=none smtp.client-ip=209.85.214.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="flnj9Hdu" Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-297f35be2ffso48739845ad.2 for ; Sun, 30 Nov 2025 04:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764504010; x=1765108810; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=aQd35PH24a+FaKSHTZdH0PU1afDBrWjh77AhHAe0IZ0=; b=flnj9HduvsSAAsCq1IEPWDGs2ixhmrHE/yjHssGneY0XYzmOwrPlYzZAt0Dp3+tubN GH6XT5kxvijc/ie5kLshfW+IdYs+ElA97So/4JUrGB7RmhZ4uKZbt8vyOnE3JyZVkE99 YkC77134J/VYN1uKYLlEAob9h0yhBtkOCrsj6TmhfHzWA0DBa32MVPLIm8ZAERTtk/jA +pZ0i/bcbqFRAhD3Ig/azVPhzdYhc6lggmSsZpfLnbpKhBXt1QVmSnB83l5EATt/4mMI ZusJRUxxrkP0HH3pmx/+JrZO4AtBMy4vk/NLCPQEKH3NBhuO+OGdXc0CRtFjOXW3O4pT ZV3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764504010; x=1765108810; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=aQd35PH24a+FaKSHTZdH0PU1afDBrWjh77AhHAe0IZ0=; b=HS2cDAb9gi7iTUfDy5nILEI0nnT+HoBpxjKmWmI9lTd0DaakwH4HvuA7PqRlq2+XWu e+qZS1bszB28c1xu8KnrSEakTgKXUF2vIF0ZNXUQvlOdo6AzmS78R3qHGTCAg1eAY/bd qGFMJ9mhKyfWwdzwK9cDtHimXsHI48sM81PX10auG53MdHRsPc/b3mFS/WECmR/HGyJv X1VMbPdTUi4XPG7pGpkt7zlun0MGUaW72sOVSrT9wVcCMMjiEDxlJstZlgL6lXv3o+VW /VzXuipJQfAIZa6nGSUFUtm89dc8+hp07F5HvYLcpmN1IoO6baVSHVqhmWz+BFTq/3Kz PTqw== X-Forwarded-Encrypted: i=1; AJvYcCU5lW+htPXa77vJgShSHov6OSaNhm3az1lSg0ZSj0xR3CExEorBtXYPFil23rruoAR0RzFinAKiRad5qf0=@vger.kernel.org X-Gm-Message-State: AOJu0Yx4Zi098abZeznJNDJhnlDVgRUbWAQ9dBOapyqxW7Eo6EJjnPZ1 EHk9Xu6rNUZpDTZUHi56ukFvylaCay1u5oRaDNLadQ4p6JHQF2QDfF6pl6yQq9JaW/c= X-Gm-Gg: ASbGnctv4ytEPN+VFPEICTBoMnxIn8wcXwWoD9kMtPE+Ba3Se/CUjFfJxTV/SsuXMTb VHv1zeeZYKJmReZPnMnoYmqRLLDL/BlSZyJh/hl3DXOq1EaEc7H2iRpBYzyho1PZOOc95A1gxbW v7HR/q1B0xQlLyi6KmxdRuKmpXAxxZc3+F/vYQqeTK5yFc1+FbOF1/CMy4pWKDeDtolc+tDTHcb UjL+l1LK69aolb3tKFwSsTVrHSE782Ng7QDcO1HX9IDPuG1JxXKFzQlJkOlVQkv8SxAO0Ug9S7s yuYDzVBOag6C/NFC+2O1qCS2K+N38M8sIvFTREFIog1H6+K9SGJAtnKmNsOPKyVX9ZDuG1u6hYI YN+uRt4WFRei42m0pEQnaRoRxkUXCY2xYBaND8hWpJcmXEJC252B9tlzsCg+BQlVDPjfW7mrKwC zCWTiBTeCXK55AHR38ik4InTVEk9ScuA== X-Google-Smtp-Source: AGHT+IEk5MXOYDcGHxwwdm3YRUkUxYKO1VcgJ2C5YDWX7CP15PKJG4iQUJiQj0Nn0ZXG2Nhli1PWtg== X-Received: by 2002:a17:903:2c0d:b0:295:39d9:8971 with SMTP id d9443c01a7336-29b6c3db364mr409791765ad.1.1764504010168; Sun, 30 Nov 2025 04:00:10 -0800 (PST) Received: from LilGuy ([2409:40c2:1165:4907:48d2:1e37:4c68:acd9]) by smtp.googlemail.com with ESMTPSA id d9443c01a7336-29bceb40ac4sm93762855ad.77.2025.11.30.04.00.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 30 Nov 2025 04:00:09 -0800 (PST) From: Swaraj Gaikwad To: Mike Rapoport , Andrew Morton , linux-mm@kvack.org (open list:MEMBLOCK AND MEMORY MANAGEMENT INITIALIZATION), linux-kernel@vger.kernel.org (open list) Cc: skhan@linuxfoundation.org, david.hunter.linux@gmail.com, Swaraj Gaikwad Subject: [PATCH RFC] mm/memblock: Fix reserve_mem allocation overlapping KHO scratch regions Date: Sun, 30 Nov 2025 17:29:39 +0000 Message-ID: <20251130172939.574999-1-swarajgaikwad1925@gmail.com> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Currently, `reserve_mem=3D` does not check for overlap with these KHO scratch areas. As a result, a memblock allocation may land inside a KHO-provided scratch region, leading to corruption or loss of the data. Noted by the following TODO: /* TODO: Allocation must be outside of scratch region */ This RFC proposes extending `reserve_mem()` to allocate memory *only* in gaps outside the KHO scratch intervals. The logic is: 1. Walk through all KHO scratch ranges (kho_scratch[]). 2. Attempt allocation in each safe gap: [curr_start_addr, scratch_start) 3. If not found, attempt to allocate after the last scratch block. 4. If all attempts fail, return -ENOMEM. The allocation is done via `memblock_phys_alloc_range()`, which already supports constrained range allocation and preserves alignment guarantees. This is posted as an RFC because I would like feedback on: - Whether the allocation-gap scanning approach is acceptable. - Whether this logic belongs in reserve_mem() or should be abstracted into a helper for reuse. - I would appreciate guidance on testing this change. Signed-off-by: Swaraj Gaikwad --- mm/memblock.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/mm/memblock.c b/mm/memblock.c index e23e16618e9b..7605a0b2b64e 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -2684,8 +2684,22 @@ static int __init reserve_mem(char *p) if (reserve_mem_kho_revive(name, size, align)) return 1; - /* TODO: Allocation must be outside of scratch region */ - start =3D memblock_phys_alloc(size, align); + phys_addr_t scratch_start, scratch_end; + phys_addr_t curr_start_addr =3D 0; + phys_addr_t alloc_end_addr =3D MEMBLOCK_ALLOC_ACCESSIBLE; + unsigned int i; + + for (i =3D 0; i < kho_scratch_cnt; i++) { + scratch_start =3D kho_scratch[i].addr; + scratch_end =3D kho_scratch[i].addr + kho_scratch[i].size; + alloc_end_addr =3D scratch_start; + if (alloc_end_addr > curr_start_addr) { + start =3D memblock_phys_alloc_range(size, align, curr_start_addr, alloc= _end_addr); + if (start) + break; + } + curr_start_addr =3D scratch_end; + } if (!start) return -ENOMEM; base-commit: 2178727587e1eaa930b8266377119ed6043067df -- 2.52.0