From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 BA5B9224AF9 for ; Tue, 18 Aug 2026 00:51:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787014262; cv=none; b=q/Xp736HiyD8nUO+F8Rl6sZeglSxoy+bnfAO8ULHfOlTwy0cL/wP/5YIYsurhzSdxuiAhuVQVsMfVF/oO4ItYL+JwWczUlj9GeqsYAnkb/L2/XxgQc7KbCDaluLUQ7ytal6cs5Ovv5UgPvCAYznmtxjmRYwS2DK6URJFFq3VvD8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787014262; c=relaxed/simple; bh=KgY3YPSvJ88qexXRKsqYzDb/xefoAjzOzZ9ryO3tKMQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TWH8hBo0Jc1tnFXatSI9Dgcn7FDyjyMASJToBUcNzW0lBwvf6CpM1nILMcJm1hXV83N78TbozCER338hsot7YWYl2GxrTQBhFCOrfph5snWGE1I6TZb5O/sVvRMIuRgln/Mn8gVNPUOG0yhSMlxPhpQei9e1OjW+iRfMK4+T5XA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mOIy4XAt; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mOIy4XAt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6581F1F000E9; Tue, 18 Aug 2026 00:51:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787014261; bh=HAo3mj35bMKVyA+WQx6ie7qsjBC0OY0XZUzTIFcDYRY=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=mOIy4XAtMF1EaYAtHJCzs8bkHOds93qkjM8FrgqHH+bkltBN3F8NEy0QTaeRmv6mL bXU5yX4rosIcHXDE/7zm+5neHzf0gBAE+uwP8Gc7wMUrLFZoBsIhK6ECzTLnvf0qCB naqX8EMciR1iY6WOwkJPDZYE0D/bSJP8r3xM3P01F8cE3dunjN4iSKDX/bI0TltfNp xA6c0b9L7FDBcnKbBnUWMpTYsyF0D/QhTSh4gZuM7PcluFs2SMK/HhkhFPib8vPSKz 6nB4KYgvx7e+866hDsbKVMKoQWTdqOZgmHj3HSGxS6tgWF6ITxS495eXqiQ9wLlHh/ wp1Ad1RA5qfuw== Date: Tue, 18 Aug 2026 00:50:59 +0000 From: Yosry Ahmed To: Brendan Jackman Cc: Borislav Petkov , Dave Hansen , Peter Zijlstra , Andrew Morton , David Hildenbrand , Vlastimil Babka , Mike Rapoport , Wei Xu , Johannes Weiner , Zi Yan , Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org, Sumit Garg , Will Deacon , rientjes@google.com, patrick.roy@linux.dev, "Itazuri, Takahiro" , Andy Lutomirski , David Kaplan , Thomas Gleixner , Patrick Bellasi , Reiji Watanabe , Sean Christopherson Subject: Re: [PATCH v3 21/26] mm/page_alloc: implement FREETYPE_UNMAPPED allocations Message-ID: References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> <20260726-page_alloc-unmapped-v3-21-6f5729aa9832@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sat, Aug 15, 2026 at 03:30:44PM +0100, Brendan Jackman wrote: > On Fri Aug 7, 2026 at 1:16 AM BST, Yosry Ahmed wrote: > >> diff --git a/mm/compaction.c b/mm/compaction.c > >> index 67b01af024e17..c9eb3947ffc79 100644 > >> --- a/mm/compaction.c > >> +++ b/mm/compaction.c > >> @@ -1393,6 +1393,9 @@ static bool suitable_migration_source(struct compact_control *cc, > >> block_ft = get_pageblock_freetype(page); > >> block_mt = free_to_migratetype(block_ft); > >> > >> + if (freetype_unmapped(get_pageblock_freetype(page))) > >> + return false; > >> + > >> /* > >> * CMA pages can only be taken by ALLOC_CMA requests. For anybody > >> * else, vacating a CMA block consumes free pages the caller > >> @@ -1444,6 +1447,9 @@ static bool suitable_migration_target(struct compact_control *cc, > >> return false; > >> } > >> > >> + if (freetype_unmapped(get_pageblock_freetype(page))) > >> + return false; > >> + > > > > Do we also want to add safety checks in the page migration code? IIUC, > > if we miss a check in the compaction code and try to compact an > > unmapped pageblock the kernel will crash with a #PF in supervisor > > mode. > > Shrug, yeah I would certainly be happy with sprinkling some more > > if (WARN_ON(freetype_unmapped(...))) > return -1; > > here and there. But yeah this feels like a maintainer preference / > philosophy question :D If the machine is gonna crash quite clearly > anyway maybe it's not worth it, I dunno. Hmm not necessarily crash? Right now if we do miss a check and end up trying to migrate an unmapped page we will crash (we actually do, will respond separately). If migration fails, I assume compaction will just fail and we might end up with more reclaim or OOMs, but not necessarily crash? Migration is where we actually access memory, so having checks there to avoid crashes (when possible) seems worthwhile. > > >> if (cc->ignore_block_suitable) > >> return true; > >> >