The compaction_test memory selftest introduces fragmentation in memory and then tries to allocate as many hugepages as possible. This series addresses some problems. On Aarch64, if nr_hugepages == 0, then the test trivially succeeds since compaction_index becomes 0, which is less than 3, due to no division by zero exception being raised. We fix that by checking for division by zero. Secondly, correctly set the number of hugepages to zero before trying to set a large number of them. Now, consider a situation in which, at the start of the test, a non-zero number of hugepages have been already set (while running the entire selftests/mm suite, or manually by the admin). The test operates on 80% of memory to avoid OOM-killer invocation, and because some memory is already blocked by hugepages, it would increase the chance of OOM-killing. Also, since mem_free used in check_compaction() is the value before we set nr_hugepages to zero, the chance that the compaction_index will be small is very high if the preset nr_hugepages was high, leading to a bogus test success. This series applies on top of the stable 6.9 kernel. Changes in v2: - Handle an unsigned long number of hugepages - Combine the first patch (previously standalone) with this series Link to v1: https://lore.kernel.org/all/20240513082842.4117782-1-dev.jain@xxxxxxx/ https://lore.kernel.org/all/20240515093633.54814-1-dev.jain@xxxxxxx/ Dev Jain (3): selftests/mm: compaction_test: Fix bogus test success on Aarch64 selftests/mm: compaction_test: Fix incorrect write of zero to nr_hugepages selftests/mm: compaction_test: Fix bogus test success and reduce probability of OOM-killer invocation tools/testing/selftests/mm/compaction_test.c | 85 ++++++++++++++------ 1 file changed, 60 insertions(+), 25 deletions(-) -- 2.34.1
