Re: [PATCH v3 1/3] selftests/mm: allow PUD-level entries in compound testcase of hmm tests

[Aboorva Devarajan <aboorvad@linux.ibm.com>]

On Mon, 2026-06-15 at 10:16 +1000, Balbir Singh wrote:
> On Thu, Jun 11, 2026 at 09:11:00AM +0530, Aboorva Devarajan wrote:
> > From: Sayali Patil <sayalip@linux.ibm.com>
> > 
> > The HMM compound testcase currently assumes only PMD-level mappings and
> > fails on systems where default_hugepagesz=1G is set, because the region
> > is then reported by the device at PUD level.
> > 
> > Determine the mapping level (PMD or PUD) the device reports for the first
> > page of the range and require every page to match that level exactly via
> > ASSERT_EQ(). This accepts PUD-level mappings while preserving the
> > expected/observed protection values printed on failure, and rejects a
> > fragmented mapping that mixes PMD- and PUD-level entries within the same
> > range (which a per-page OR check would have let pass).
> > 
> 
> PUD is not supported with zone device private folios, the fix should
> be really around default_huge_page_size(), using the default pmd size.
> 
> Balbir


Thanks Balbir for the review.

IIUC, PUD not-supported restriction applies to the migration path
(device-private folios top out at PMD), which the migrate_* tests cover but compound
is purely a snapshot of the CPU page tables, where a 1G hugetlb page can
shows up at PUD. I guess HMM_DMIRROR_PROT_PUD was in fact added in e478425bec93
(the same commit this patch Fixes:) to express PUD-sized snapshot entries,
so handling it here is using the bit for its original purpose. I verified the v3 patch
passes on a default_hugepagesz=1G boot (m[i] == WRITE|PUD), and fails without it.

But if you'd still prefer to keep this test-case strictly PMD-only, please let us know.

Regards,
Aboorva