From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-214.mta1.migadu.com [95.215.58.214]) (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 268FC495534 for ; Thu, 13 Aug 2026 16:44:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.214 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786639453; cv=none; b=Otp27TZQciSBg9FvNY872g3N9ASDd6pv/riUBTt9ycHr18Tu1rn9NY9Ijwwi7d1BF0A8rT/INs01+eWFp7IVO1X0r+Rz3r3GGi/ZFUoJcAh3PIZLjzVajcX3S0r2+AlYVZJTY4lKki+VJTHKeaTHjPBBrSOJ3LcDDdRJtmd6L8I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786639453; c=relaxed/simple; bh=dGeEWnoB/VRmNpMiEGQ7yG96SirN+Gr0AYqUVuvNOK0=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=mkZZs/afWMheGdg6eCQY3KkizyJFj+Te7a2eOR7On04I5oFtpW106AgM17PyBrYoWo+sEGH168aFJKcwxtrOIBsct4QELcC4pABHiOhCjWHVjbXMccDefCexkDi1yOU9qfoxOSLM6RQjAbkNz7pJ76eqbWEyYhdq3EozQq3US2I= 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=qg+QIEeg; arc=none smtp.client-ip=95.215.58.214 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="qg+QIEeg" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=dGeEWnoB/VRmNpMiEGQ7yG96SirN+Gr0AYqUVuvNOK0=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786639447; v=1; x=1787244247; b=qg+QIEegBPbxMNd9bG9JqY4tJUAXjUf3sbzIFSWcigcD54camBqi+aKYoeBroGiCZlYK7dDF PUYrZP7hXAaQwcOv79kzyEotYQv18hZ07F78J2i1PHznD422ozY2hhE4uOP4EfrM6SSPpNw2AnX zNvQnvv85MFJzt98odK1jWRo= X-Envelope-To: linux-kernel@vger.kernel.org Received: from localhost (77.97.51.77) by smtp.migadu.com with ESMTPS id bc8c564863385aad; Thu, 13 Aug 2026 16:44:07 +0000 X-Migadu-Flow: FLOW_OUT 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 Date: Thu, 13 Aug 2026 17:44:05 +0100 Message-Id: Cc: "Borislav Petkov" , "Dave Hansen" , "Peter Zijlstra" , "Andrew Morton" , "David Hildenbrand" , "Vlastimil Babka" , "Wei Xu" , "Johannes Weiner" , "Zi Yan" , "Lorenzo Stoakes" , , , , "Sumit Garg" , "Will Deacon" , , "Kalyazin, Nikita" , , "Itazuri, Takahiro" , "Andy Lutomirski" , "David Kaplan" , "Thomas Gleixner" , "Yosry Ahmed" , "Patrick Bellasi" , "Reiji Watanabe" , "Sean Christopherson" Subject: Re: [PATCH v3 11/26] x86/mm: introduce the mermap From: "Brendan Jackman" To: "Mike Rapoport" , "Brendan Jackman" X-Mailer: aerc 0.21.0 References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> <20260726-page_alloc-unmapped-v3-11-6f5729aa9832@google.com> In-Reply-To: On Sun Aug 2, 2026 at 5:40 PM BST, Mike Rapoport wrote: ... >> + >> +VISIBLE_IF_KUNIT void __mermap_put(struct mm_struct *mm, struct mermap_= alloc *alloc) >> +{ >> + unsigned long size =3D PAGE_ALIGN(alloc->end - alloc->base); >> + >> + __apply_to_page_range(mm, alloc->base, size, set_unmapped_pte, >> + NULL, PGRANGE_CREATE | PGRANGE_NOLOCK); >> + > > Sorry if I missed that in previous discussions. > > __apply_to_page_range() acts only on PTE mappings, and looking forward I > presume we'd want PMD and maybe event PUD mappings in guest_memfd and > subsequently in mermap. Yeah. > We anyway have a ton of page table walkers, so maybe it'll make sense to > add yet another one rather than adjust __apply_to_page_range() to the > mermap needs? Yeah... I would really like to avoid creating another. This was basically the topic of my last LSF/MM/BPF session that I pivoted away from at the last minute coz I just don't really have a clear idea of how to proceed. I feel like maybe the way forward is to try and pick one and slowly steer it towards being generic enough to subsume another one? Like maybe we could target incrementally converging the set_memory and __apply_to_page_range implementations or something... > Or maybe there's a suitable walk_ API in mm/pagewalk.c? I think that code is all pretty tailored towards _inspecting_ instead of modifying.