From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-180.mta0.migadu.com (out-180.mta0.migadu.com [91.218.175.180]) (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 234A132AABA for ; Wed, 1 Apr 2026 02:29:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775010571; cv=none; b=bnEIMlNYiE/cNJF/Zr3oRLxo+DZuN6MhHX7al6KJqkxHwsowk/GlnJ4cmKiyDNquF9GwiKZqveL0STThnvjkKLyKVsW3GOHZj2zGy8dcmQDwTWFZyrJIxEgPNrqB3X/sNspfJc3emdCDtn/kCHDbi3khxSbsDGZq/JUZpr32yEA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775010571; c=relaxed/simple; bh=clKU1bqilv281vjHZn0PzIEHgK+5fzl4+uThEvbMAAo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=p/9wvDKqwIUCglaZGrGH5jXvLX4fQcaBli5qa8JUGkiYfT94a6njrD3FEDqZJ7z9DX84wvF5pMaDZyW5sAyUwPNrcHiHQA7mqZN3TjB9LieCVnwNeb6IP1XACuE0oFIlUGnHJEpoaKNiLseIbDjb10wHIMvrrAOSxfgOKoZozIo= 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=E184uyre; arc=none smtp.client-ip=91.218.175.180 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="E184uyre" Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1775010567; 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=T+gopcYDxtZS/MQGedY6a0sVbuszfaaXXdUw6JqGvTg=; b=E184uyreOv+bMn3jPQ1UAdErOCUrE6k1+N1qtizL0LXUifPANyAGJovVuayaMu37IQE0MC m10n5cQ4a8X/7pCfoguypsbHG2jGz/rb4ysVeLi6Z+F5SYb0aA2TiKw+6cjr3TLlOdfpES lCy5ioMsijIYBDMdQQn7vTLP/oZW6cY= 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.400.21\)) Subject: Re: [PATCH] mm/sparse: fix preinited section_mem_map clobbering on failure path X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <81857888-b6aa-4f04-bfd7-e9365d62669d@linux.ibm.com> Date: Wed, 1 Apr 2026 10:28:41 +0800 Cc: Muchun Song , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Frank van der Linden , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <1ACF04AC-CC9B-4B29-8E3F-6609B5C1B09E@linux.dev> References: <20260331113724.2080833-1-songmuchun@bytedance.com> <81857888-b6aa-4f04-bfd7-e9365d62669d@linux.ibm.com> To: Donet Tom X-Migadu-Flow: FLOW_OUT > On Apr 1, 2026, at 02:34, Donet Tom wrote: >=20 > Hi Muchun Hi, >=20 > On 3/31/26 5:07 PM, Muchun Song wrote: >> sparse_init_nid() is careful to leave alone every section whose = vmemmap >> has already been set up by sparse_vmemmap_init_nid_early(); it only >> clears section_mem_map for the rest: >>=20 >> if (!preinited_vmemmap_section(ms)) >> ms->section_mem_map =3D 0; >>=20 >> A leftover line after that conditional block >>=20 >> ms->section_mem_map =3D 0; >>=20 >> was supposed to be deleted but was missed in the failure path, = causing the >> field to be overwritten for all sections when memory allocation = fails, >> effectively destroying the pre-initialization check. >>=20 >> Drop the stray assignment so that preinited sections retain their >> already valid state. >>=20 >> Fixes: d65917c42373 ("mm/sparse: allow for alternate vmemmap section = init at boot") >> Signed-off-by: Muchun Song >> --- >> mm/sparse.c | 1 - >> 1 file changed, 1 deletion(-) >>=20 >> diff --git a/mm/sparse.c b/mm/sparse.c >> index c2eb36bfb86d..3a14b733bf71 100644 >> --- a/mm/sparse.c >> +++ b/mm/sparse.c >> @@ -584,7 +584,6 @@ static void __init sparse_init_nid(int nid, = unsigned long pnum_begin, >> ms =3D __nr_to_section(pnum); >> if (!preinited_vmemmap_section(ms)) >> ms->section_mem_map =3D 0; >> - ms->section_mem_map =3D 0; >=20 >=20 > This looks correct to me. >=20 > I have a couple of questions: >=20 > 1. As I understand, section_mem_map initially stores the nid > during early boot, and later it stores a pointer to an > array of struct page. In sparse_init_nid(), the struct page > array is stored in section_mem_map via > sparse_init_early_section(). If > __populate_section_memmap() fails, we are clearing the nid > stored in section_mem_map right? Right. >=20 > 2. Another question: if sparse_init_nid() fails for some > sections, there is no retry mechanism to add them again, > correct? Right. >=20 > 3. when ms->section_mem_map is set to 0 > for a pre-initialized section, does it only affect the > pre-initialization check, or could it lead to other issues? >=20 Only affect pre-initialization. No other issues. Thanks. >=20 > - Donet >=20 >> } >> }