From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-164.mta1.migadu.com (out-164.mta1.migadu.com [95.215.58.164]) (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 200B24399C0 for ; Tue, 4 Aug 2026 11:11:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.164 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785841874; cv=none; b=s30ARXGXv3r0nnK9jqkc16G19qycMWsbx2z1d0Yaqpulv8HkNXmawX0HeuUrcd6iqUeHNDQ1D2h+Tq7m9YoZqWVAXtOMduKW37GTHI+81uu5RATFHa/xtv8fp7dPfwfGDdsvYU7BDPVdbNNerAgMXDLQm7U2n4x5NEs7B7+EkIs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785841874; c=relaxed/simple; bh=Gb/a2koC3CcID8BoqGlv6giBKM9i9xztj57SPl7whEM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=INA+QGNpl8QqWZDjYKHm13Shfn9P9mwqnamXCU6qbJAYpWe+Dl7zHbEbYoq8NLWDG15aKw79Dm0iH7XZtuLR/WZ3Mg11yc714LHkuJ1SAHKw/1lIKYoputTEQpAkQ2mZbFVhtq2sq3FPpfKJ847ioR3gNQTOAhiKbklxfoyMyRA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=pENtFhKN; arc=none smtp.client-ip=95.215.58.164 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="pENtFhKN" Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785841870; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hXdQdLXk3DZj8XyxfTld1Y9wOF/hPoBLP3p20wObD2s=; b=pENtFhKNVLZQk5LpJk8jZHmxaccxVINc33LymFRkBbJY8kjTIhsyWiV7F4a1geeoeqDsr3 hU9LqndipGiSVW6Dx9Vgs0uVDns4+LDEZpCaGP+k8HLGqY66bZv5Uq84a+/zctG5BjtOfC kHBwhDM6bQH3QOyNa4203XiB7nbXyFw= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Subject: Re: [PATCH] mm/sparse: keep mem_section_usage_size() internal X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <9314195a-2704-42da-8251-d2df618d630e@kernel.org> Date: Tue, 4 Aug 2026 19:10:50 +0800 Cc: Muchun Song , Andrew Morton , linux-mm@kvack.org, Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <06FBFFEA-BFC6-4F97-BE21-0574FA3FACA7@linux.dev> References: <20260804100114.16627-1-songmuchun@bytedance.com> <9314195a-2704-42da-8251-d2df618d630e@kernel.org> To: "David Hildenbrand (Arm)" X-Migadu-Flow: FLOW_OUT > On Aug 4, 2026, at 18:09, David Hildenbrand (Arm) = wrote: >=20 > On 8/4/26 12:01, Muchun Song wrote: >> mem_section_usage_size() is only needed by sparsemem implementation = code, >> but declaring it in mmzone.h makes the helper visible to all mmzone.h >> users. >=20 > Worth mentioning that >=20 > commit ae751d567baa08342e5e34b378b72a6f9b2cfada > Author: David Hildenbrand (Arm) > Date: Mon May 11 16:05:34 2026 +0200 >=20 > mm/bootmem_info: stop marking mem_section_usage as MIX_SECTION_INFO >=20 > Remove the last external user. Will do. >=20 >>=20 >> Move the helper to sparse.h so sparse.c and sparse-vmemmap.c can = share >> it through the internal header. While doing so, calculate the = allocation >> size with struct_size(), which ties the expression to the = pageblock_flags >> trailing array instead of open-coding the struct header plus bitmap = size. >>=20 >> Signed-off-by: Muchun Song >> --- >> include/linux/mmzone.h | 1 - >> mm/sparse.c | 10 ---------- >> mm/sparse.h | 6 ++++++ >> 3 files changed, 6 insertions(+), 11 deletions(-) >>=20 >> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h >> index a26c8b855222..86891163e0ef 100644 >> --- a/include/linux/mmzone.h >> +++ b/include/linux/mmzone.h >> @@ -2070,7 +2070,6 @@ static inline struct mem_section = *__nr_to_section(unsigned long nr) >> #endif >> return &mem_section[root][nr & SECTION_ROOT_MASK]; >> } >> -extern size_t mem_section_usage_size(void); >>=20 >> /* >> * We use the lower bits of the mem_map pointer to store a little bit = of >> diff --git a/mm/sparse.c b/mm/sparse.c >> index 704a9dec2b9a..46458e5300e2 100644 >> --- a/mm/sparse.c >> +++ b/mm/sparse.c >> @@ -213,16 +213,6 @@ static void __init memblocks_present(void) >> memory_present(nid, start, end); >> } >>=20 >> -static unsigned long usemap_size(void) >> -{ >> - return BITS_TO_LONGS(SECTION_BLOCKFLAGS_BITS) * sizeof(unsigned = long); >> -} >> - >> -size_t mem_section_usage_size(void) >> -{ >> - return sizeof(struct mem_section_usage) + usemap_size(); >> -} >> - >> #ifdef CONFIG_SPARSEMEM_VMEMMAP >> unsigned long __init section_map_size(void) >> { >> diff --git a/mm/sparse.h b/mm/sparse.h >> index 95aa031213f2..4960a17b706f 100644 >> --- a/mm/sparse.h >> +++ b/mm/sparse.h >> @@ -47,6 +47,12 @@ static inline void __section_mark_present(struct = mem_section *ms, >>=20 >> ms->section_mem_map |=3D SECTION_MARKED_PRESENT; >> } >> + >> +static inline size_t mem_section_usage_size(void) >> +{ >> + return struct_size((struct mem_section_usage *)NULL, = pageblock_flags, >> + BITS_TO_LONGS(SECTION_BLOCKFLAGS_BITS)); >> +} >=20 > There is struct_size_t() that avoids the manual "NULL" trick. I hadn't noticed that API before. Thanks for the heads-up. I'll send a v2 to fix this. Muchun, Thanks. >=20 > --=20 > Cheers, >=20 > David