From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 2646D34107A for ; Wed, 18 Mar 2026 20:39:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773866399; cv=none; b=RZ1Bb4X0NcaC3t/1mipfue+pKrK1Nmz45xgKpyMVfC+2gEfHIZXWsH++RFgY0QEQO5cAtfeUw/JZfMlZ7y/RHPrgawrF38V2KU5ff1rt0gRm5B37UQIBmYz4AZcBgtAy8clvnCE5iX/BubyEJq/p8UcOR8wUq1OA0CEFY2CiffY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773866399; c=relaxed/simple; bh=pYIzPtSNloAItmJiIn0iH8Q4EDjnMU64MDsdWgcCmmo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=adSppAQSwsZcLMOuQQ2h2KKv+w1Ojer4rSDlozzXoo14mn+/RwMA6JTfx9dVFkBZTCvAajFjmgiZrLdS48N3yJADesRjJTpfwxUogzMLz0NrRRpUAOY0dkVShEAnqCsw+NVIl2lvClfxkXQLjxOuchn4SHdAwMLuF9n3wMJo5bw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QVHEw6t9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QVHEw6t9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C848C19421; Wed, 18 Mar 2026 20:39:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773866399; bh=pYIzPtSNloAItmJiIn0iH8Q4EDjnMU64MDsdWgcCmmo=; h=From:To:Cc:Subject:Date:From; b=QVHEw6t96bKEDLTYzSSy8Fsu+Zo+ksc/uUSRKP3j8a5tnS9RLaR2k8R2Q/8/mbIRN TvobnKtOSi7C1hhRDLLQN0KnLOTBG5fUDtVKq2YAfLCCCd7b9SgSKRHtfKl/M7SCJw dYciXiyC5sv8otBNkyBXgS2KmcD84HAllJgMMuY9YxIEFdR4R0+cLH/MX5HbFVZ2QI 7E2qQ4auT7iSMMVsCswvtH7olv/QZ9hx+AbJo3qaUGUQJmhooh5N/wHIDJQLqpmQBo uVGpBLQ1D1AQ2lmzBjxrnPKpE0vh94W8Rm2hjOLOz/4V+JX5kFHrggH+M+lI2m92Ze CfjbZ9uVDd3/A== From: "Lorenzo Stoakes (Oracle)" To: Andrew Morton Cc: David Hildenbrand , Zi Yan , Baolin Wang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/8] mm/huge_memory: refactor zap_huge_pmd() Date: Wed, 18 Mar 2026 20:39:22 +0000 Message-ID: X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The zap_huge_pmd() function is overly complicated, clean it up and also add an assert in the case that we encounter a buggy PMD entry that doesn't match expectations. This is motivated by a bug discovered [0] where the PMD entry was none of: - A non-DAX, PFN or mixed map. - The huge zero folio - A present PMD entry - A softleaf entry In zap_huge_pmd(), but due to the bug we manged to reach this code. It is useful to explicitly call this out rather than have an arbitrary NULL pointer dereference happen, which also improves understanding of what's going on. [0]:https://lore.kernel.org/all/6b3d7ad7-49e1-407a-903d-3103704160d8@lucifer.local/ Lorenzo Stoakes (Oracle) (8): mm/huge_memory: simplify vma_is_specal_huge() mm/huge: avoid big else branch in zap_huge_pmd() mm/huge_memory: have zap_huge_pmd return a boolean, add kdoc mm/huge_memory: handle buggy PMD entry in zap_huge_pmd() mm/huge_memory: add a common exit path to zap_huge_pmd() mm/huge_memory: remove unnecessary VM_BUG_ON_PAGE() mm/huge_memory: deduplicate zap deposited table call mm/huge_memory: deduplicate zap_huge_pmd() further by tracking state include/linux/huge_mm.h | 8 +-- include/linux/mm.h | 16 ----- mm/huge_memory.c | 145 +++++++++++++++++++++++----------------- 3 files changed, 89 insertions(+), 80 deletions(-) -- 2.53.0