From nobody Mon Feb 9 22:50:32 2026 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 83F0C1F5617; Tue, 4 Mar 2025 07:27:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741073265; cv=none; b=dI3jRPtNnCTwRt7gFG15cx/UjUAGarbHvS4RdpmEPnZ7F77iJgZFmXnIw7fl+k0sTq8XUm+gvZzqIa4O6V16Cty/dxHl6M0OiVX5BJdWF3wwuDM05SrD8Hukl6td050WOrYgMvxXrYphk4Q/GZ7eVFxQmpth+qQ9ig12CwYdOIc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741073265; c=relaxed/simple; bh=cfMn2uFgmBUoBrG/SvHJ4//7uy8o9dISSHFMfarLP5c=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=BWEQVqvtctTibZGZs4jdNShxI/PKk2S0XMaiFshHEIXD2l8+VJX8N8xhYQShRdMAqBjtWha+XPGx+LSWwHgLB+mIgifBNcIq/i+i82/qSE6ukj1xugEPavtGUD/fCQaNv4qOwv0+CzrkyOtQi52EV2usvFedvqPZSbs8USNeowo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com; spf=pass smtp.mailfrom=quicinc.com; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b=MP3UWa8F; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=quicinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="MP3UWa8F" Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 523NXXo8007052; Tue, 4 Mar 2025 07:27:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= cc:content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to; s=qcppdkim1; bh=cz8mwoQe3GYg7tuptNj/As da9H316llc4gDpuYCBPHQ=; b=MP3UWa8Frj5QM1eDEGIuUVYiIGXAsQopuF5PEd lIZDU+XQE3UTR0lT1Mu1qvZyi37PboVW36HpnFHZA4rLxV9FSu1DnNaj60zVCTQO nxwOIkikHizH2RUqVtdNhvl4cjJOJA42nWHae8/9lpvWtOeDPEhelnbX85GVItsN McWWNnQUKnX645yBZvSw7W6nm5ttaxb8h4cDL5kRRNXs5EC5iu3uUd0fJreozcD1 g56Jc5BWdkP1WNz4iDYEpyS3Z4HZbyeAHGYIY9I4BmemnpkyMTw5Uy6/8GxguNg2 fGEbwST74eDKYTfrFS6zErV09yOwufH232v+H9r/C/t3DpdA== Received: from nalasppmta04.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 455p6th0v8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 04 Mar 2025 07:27:22 +0000 (GMT) Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA04.qualcomm.com (8.18.1.2/8.18.1.2) with ESMTPS id 5247RLbv014113 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 4 Mar 2025 07:27:21 GMT Received: from ap-kernel-sh01-lnx.qualcomm.com (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.9; Mon, 3 Mar 2025 23:27:16 -0800 From: Zhenhua Huang To: , , CC: , , , , , , , , , , , , , Zhenhua Huang , Subject: [PATCH v9] arm64: mm: Populate vmemmap at the page level if not section aligned Date: Tue, 4 Mar 2025 15:27:00 +0800 Message-ID: <20250304072700.3405036-1-quic_zhenhuah@quicinc.com> X-Mailer: git-send-email 2.25.1 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 X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Authority-Analysis: v=2.4 cv=HZbuTjE8 c=1 sm=1 tr=0 ts=67c6ab5a cx=c_pps a=ouPCqIW2jiPt+lZRy3xVPw==:117 a=ouPCqIW2jiPt+lZRy3xVPw==:17 a=GEpy-HfZoHoA:10 a=Vs1iUdzkB0EA:10 a=VwQbUJbxAAAA:8 a=20KFwNOVAAAA:8 a=COk6AnOGAAAA:8 a=NceqpOgtns4pJs_QtpcA:9 a=TjNXssC_j7lpFel5tvFf:22 X-Proofpoint-GUID: IPE3Tm_3UXzTcBxsIgZ8AE2r4qJy0ZOf X-Proofpoint-ORIG-GUID: IPE3Tm_3UXzTcBxsIgZ8AE2r4qJy0ZOf X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1093,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-03-04_03,2025-03-03_04,2024-11-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 adultscore=0 mlxscore=0 spamscore=0 clxscore=1015 phishscore=0 bulkscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 classifier=spam authscore=0 adjust=0 reason=mlx scancount=1 engine=8.19.0-2502100000 definitions=main-2503040061 Content-Type: text/plain; charset="utf-8" On the arm64 platform with 4K base page config, SECTION_SIZE_BITS is set to 27, making one section 128M. The related page struct which vmemmap points to is 2M then. Commit c1cc1552616d ("arm64: MMU initialisation") optimizes the vmemmap to populate at the PMD section level which was suitable initially since hot plug granule is always one section(128M). However, commit ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug") introduced a 2M(SUBSECTION_SIZE) hot plug granule, which disrupted the existing arm64 assumptions. The first problem is that if start or end is not aligned to a section boundary, such as when a subsection is hot added, populating the entire section is wasteful. The next problem is if we hotplug something that spans part of 128 MiB section (subsections, let's call it memblock1), and then hotplug something that spans another part of a 128 MiB section(subsections, let's call it memblock2), and subsequently unplug memblock1, vmemmap_free() will clear the entire PMD entry which also supports memblock2 even though memblock2 is still active. Assuming hotplug/unplug sizes are guaranteed to be symmetric. Do the fix similar to x86-64: populate to pages levels if start/end is not aligned with section boundary. Cc: # v5.4+ Fixes: ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug") Acked-by: David Hildenbrand Signed-off-by: Zhenhua Huang Reviewed-by: Catalin Marinas Reviewed-by: Oscar Salvador --- arch/arm64/mm/mmu.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index b4df5bc5b1b8..1dfe1a8efdbe 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -1177,8 +1177,11 @@ int __meminit vmemmap_populate(unsigned long start, = unsigned long end, int node, struct vmem_altmap *altmap) { WARN_ON((start < VMEMMAP_START) || (end > VMEMMAP_END)); + /* [start, end] should be within one section */ + WARN_ON_ONCE(end - start > PAGES_PER_SECTION * sizeof(struct page)); =20 - if (!IS_ENABLED(CONFIG_ARM64_4K_PAGES)) + if (!IS_ENABLED(CONFIG_ARM64_4K_PAGES) || + (end - start < PAGES_PER_SECTION * sizeof(struct page))) return vmemmap_populate_basepages(start, end, node, altmap); else return vmemmap_populate_hugepages(start, end, node, altmap); --=20 2.25.1