From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-182.mta0.migadu.com (out-182.mta0.migadu.com [91.218.175.182]) (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 853B83B52E9 for ; Thu, 14 May 2026 08:20:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778746848; cv=none; b=LbNQ4BQF/ZybdHHEua2zKkCfHzD9k1wBP9wIpQ94RYhizVyPSgQixrHsaQwoG9YvaUe0WvE2MI9B4OB5OPoGtYRcLHJfjypnVL6cKRxl4OHi8T/vZdbGRnObAOofXRY+aAeu4XwUWbInkjExVyf9PiwbkcPdEoW0cpe8SsMvH/g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778746848; c=relaxed/simple; bh=eF9zsW7xnXvYZrz7iQ2MKx+MqvnRKTtP5O8YBI2NE3c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=bTVPK6P0Oamcvo5nZW3V8AJcFS0jzKoJJgjSx5bDQzlDrcLLppvrnM8HsOhF5SI0vFMi0uhDkh3Ph2a4XgPYJE2JNcZH7EHo+WExiBR7mAFWFJAj12jvzAPBj7YprQkZ5rP2D39JqAHGHM5luYwbbW+xY2Ezeon12YSfc8hCkjk= 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=KDwxvaKg; arc=none smtp.client-ip=91.218.175.182 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="KDwxvaKg" Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1778746844; 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=eF9zsW7xnXvYZrz7iQ2MKx+MqvnRKTtP5O8YBI2NE3c=; b=KDwxvaKgh9l7mgpFBVZ+HTHG5TDMhl79lW7K3ZfMryQ5xm+gJinvCPr43E41bc7FSO4UAU xg27y1DxfnLCU6Y5XwSgd/HiNCx2W+k3aOiQfCwlb22XLvPX1xKbHpaPTswYw7yqpDHi4i Qy7K2XvZmO+OLALVUA8mkSffbYKzz3c= 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.500.181\)) Subject: Re: [PATCH v2 02/69] mm/hugetlb_vmemmap: Fix __hugetlb_vmemmap_optimize_folios() X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Thu, 14 May 2026 16:19:58 +0800 Cc: Muchun Song , Andrew Morton , David Hildenbrand , Michael Ellerman , Madhavan Srinivasan , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Nicholas Piggin , Christophe Leroy , Ackerley Tng , Frank van der Linden , aneesh.kumar@linux.ibm.com, joao.m.martins@oracle.com, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <76D9FAE1-7830-495F-A98D-B3F5FC26F9CC@linux.dev> References: <20260513130542.35604-1-songmuchun@bytedance.com> <20260513130542.35604-3-songmuchun@bytedance.com> To: Oscar Salvador X-Migadu-Flow: FLOW_OUT > On May 14, 2026, at 15:56, Oscar Salvador wrote: >=20 > On Wed, May 13, 2026 at 09:04:30PM +0800, Muchun Song wrote: >> __hugetlb_vmemmap_optimize_folios() uses incorrect arguments when = handling >> bootmem HugeTLB folios. >>=20 >> The section number passed to register_page_bootmem_memmap() is = derived from >> the vmemmap virtual address of folio->page instead of the folio PFN, = so the >> bootmem memmap metadata can be registered against the wrong section. = The >> helper is also given HUGETLB_VMEMMAP_RESERVE_SIZE even though it = expects a >> page count, not a size in bytes. In addition, the write-protect range = is >> based on pages_per_huge_page(h), which does not cover the full = HugeTLB >> vmemmap area and can leave part of the shared tail vmemmap mapping = writable. >>=20 >> Fix the section lookup to use folio_pfn(folio), use >> HUGETLB_VMEMMAP_RESERVE_PAGES when registering the reserved memmap = pages, and >> use hugetlb_vmemmap_size(h) for the write-protect range. >>=20 >> Fixes: 752fe17af693 ("mm/hugetlb: add pre-HVO framework") >> Signed-off-by: Muchun Song >=20 > Acked-by: Oscar Salvador Thanks. >=20 > did you observe any Ooops or malfunctioning or was just code = reviewing? Found by LLM (Gemini Pro). When I touched the code here, LLM will report the bug as well, even it = is not introduced by me :) Thanks, Muchun >=20 >=20 >=20 > --=20 > Oscar Salvador > SUSE Labs