Re: [Devel] [PATCH hci-8.1 2/2] selftests/ve: check memory.numa_migrate keeps the folio order

[Konstantin Khorenko <khorenko@virtuozzo.com>]

On 10/28/26 13:49, Pavel Tikhomirov wrote:
>> memcg_numa_migrate_new_folio() used to allocate a PMD-sized destination
>> for every large folio. A page cache folio of a smaller order then ended
>> up with a 512-page destination carrying its index and reference count.
>> Only the source pages were copied into it, so a read of the folios that
>> followed in the same 2 MB range was served from the uninitialised part
>> of the destination, and the inode died in clear_inode() on eviction.
>>
>> The test writes a file on an XFS image, where 64K writes produce large
>> folios, from a cgroup bound to one NUMA node, migrates the cgroup to a
>> second node, checks that something was migrated and reads the file back
>> against the written pattern. On an unfixed kernel the comparison fails;
>> the test then leaves the image mounted, because unlinking or unmounting
>> would evict the inode and crash the node.
>>
>> It needs root, two NUMA nodes with memory (numa=fake=2 is enough),
>> cgroup2 with the memory and cpuset controllers, and mkfs.xfs, and skips
>> otherwise.
> 
> This case looks a bit implicit, we rely on the size of huge pages XFS
> allocates, maybe we can add folio size check, or somehow force
> allocation of proper order. This is not blocking I guess.

Agreed, v1 took the folio order on faith.
v2 will read the compound flags of the file's pages through
/proc/self/pagemap and /proc/kpageflags before the migration.

A file without a large folio fails the test, on purpose
a skip would hide that the test no longer reaches the bug,
while a failure tells us the XFS write path stopped giving large
folios on that setup and the test needs another way to get them.



_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel